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Prefácio 


A maioria dos livros sobre sistemas operacionais e' rica 
na parte teórica e inconsistente, na prática. Este, contudo, 
objetiva proporcionar um melhor equilíbrio entre ambas. 
Ele abrange todos os princípios fundamentais pormenori¬ 
zadamente, incluindo processos, comunicação interproces- 
sos, semáforos, monitores, passagem de mensagens, algo¬ 
ritmos de agendamento, entrada/saída, impasses, drivers 
de dispositivos, gerenciamento de memória, algoritmos de 
paginação, projeto de sistema de arquivos, segurança e 
mecanismos de proteção, mas, também, discute em deta¬ 
lhes um sistema particular — o MINIX, sistema operacio¬ 
nal compatível com o Unix — além de oferecer uma lista¬ 
gem completa do código-fonte para estudo. Esse arranjo 
permite que o leitor não só aprenda os princípios, mas, tam¬ 
bém, veja como são aplicados em um sistema operacional 
real. 

Quando a primeira edição deste livro foi publicada, em 
1987, causou uma pequena revolução na maneira como 
os cursos de sistemas operacionais eram ministrados. Até 
então, a maioria dos cursos somente abordava a teoria. Com 
o aparecimento do minix, muitas escolas começaram a ofe¬ 
recer aulas de laboratório, onde os alunos examinavam 
um sistema operacional real para ver como ele funcionava 
por dentro. Consideramos essa tendência muito bem-vin¬ 
da e esperamos que esta segunda edição a fortaleça. 

Nos seus primeiros 10 anos, o minix sofreu muitas mu¬ 
danças. O código original foi projetado para um IBM PC 
baseado no 8088 de 25ÓK com duas unidades de disquete e 
nenhum disco rígido. Além disso, foi baseado na Versão 7 
do UNIX. Com o tempo, o MINIX desenvolveu-se de várias 
maneiras. Por exemplo, a versão atual agora rodará em 
qualquer computador situado entre o PC original (em modo 
real de 16 bits) até poderosos Pentium com grandes discos 
rígidos (no modo protegido de 32 bits). Ele também mu¬ 
dou da antiga base na Versão 7, para basear-se no padrão 
internacional POSIX (IEEE 1003.1 e ISO 9945-1). Por fim, 
muitos recursos foram acrescentados, demais em nosso pon¬ 


to de vista, mas poucos, na visão de outras pessoas, que 
levaram à criação do LINUX. Além disso, o MINIX foi portado 
para muitas outras plataformas, para incluir o Macintosh, 
o Amiga, o Atari e as estações SPARC. Este livro abrange 
apenas o MINIX 2.0, que até agora só roda em computado¬ 
res com uma CPU 80x86, em sistemas que podem emular 
uma CPU desse tipo ou em uma estação SPARC. 

Esta segunda edição apresenta mudanças em todo o li¬ 
vro. Quase todo o material sobre princípios foi revisado, e 
considerável material novo foi acrescentado. Entretanto, a 
mudança principal é a discussão do novo minix baseado 
em POSIX, além da inclusão do novo código neste livro. Tam¬ 
bém nova é a inclusão de um CD-ROM, para oferecer o 
código-fonte completo do MINIX, com instruções para ins¬ 
talar o MINIX em um PC (veja o arquivo LEIAME.TXT no 
diretório principal do CD-ROM). 

Instalar o minix em um PC 80x86, seja para uso indivi¬ 
dual seja para um laboratório, é simples e direto. Uma par¬ 
tição de disco de pelo menos 30MB deve ser feita para ele, 
que então pode ser instalado, bastando que as instruções 
do arquivo LEIAME.TXT do CD-ROM sejam seguidas. Para 
imprimir o arquivo LEIAME.TXT em um PC, primeiro ini¬ 
cie o MS-DOS, se ele ainda não estiver rodando (a partir do 
WINDOWS, clique no ícone MS-DOS). Então digite: 

copy leiame.txt prn 

para imprimir. O arquivo também pode ser examinado no 
Edit do MS-DOS, no WordPad, no Bloco de Notas do Windows, 
ou em qualquer outro editor de texto que manipule texto 
puro em ASCII. 

Para escolas (ou indivíduos) que não dispõem de PCs, 
duas outras opções estão agora disponíveis. Foram incluí¬ 
dos dois simuladores no CD-ROM. Um, escrito por Paul 
Ashton, roda em SPARCs. Ele executa o minix como um 
programa de usuário sobre o Solaris. Como conseqüência, 
o MINIX é compilado em um binário SPARC e roda à toda 
velocidade. Deste modo, o MINIX não é mais um sistema 
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operacional, mas um programa de usuário. Portanto, fo¬ 
ram necessárias algumas mudanças no código de baixo 
nível. 

0 outro simulador foi escrito por Kevin P. Lawton da 
Bochs Software Company. Esse simulador interpreta o con¬ 
junto de instruções Intel 80386 e o suficiente do mecanis¬ 
mo de E/S para o MlNix poder rodar no simulador. Natu¬ 
ralmente, rodar em um interpretador custa algum desem¬ 
penho, mas facilita muito a depuração para o aluno. Esse 
simulador tem a vantagem de executar em qualquer com¬ 
putador que suporte o M.I.T. X Window System. Para mais 
informações sobre esses dois simuladores, veja o CD-ROM. 

O desenvolvimento do mixix é uma proposta em pro¬ 
gresso. O conteúdo deste livro e seu CD-ROM são mera¬ 
mente uma amostra do sistema na época da sua publica¬ 
ção. Para o estado atual das coisas, visite a home page do 
MINIX na World Wide Web, http ://www. cs. vu.nl/~ast/ 
minix.html. Além disso, o MINIX tem seu próprio grupo de 
discussão na USENET: comp.os.minLx, no qual os leitores 
podem inscrever-se para saber o que está acontecendo no 
mundo do MINIX. Para aqueles com correio eletrônico, mas 
sem acesso a grupos de discussão, também há uma lista de 
discussão via e-mail. Escreva para listserv@listserv. nodak. 
edu com “subscribe minix-1 <seu nomecompleto>” como 
a primeira e única linha do coqro da mensagem. Você re¬ 
ceberá mais informações pelo correio eletrônico. 

Para uso em sala de aula, a Prentice-Hall oferece um 
manual de soluções de problemas, mas apenas para pro¬ 
fessores. Os arquivos PostScript com todas as figuras no li¬ 
vro, conveniente como material didático de apoio, podem 
ser encontradas seguindo o link ' 'Software and supplemen- 
tary material " emhttp://www. cs. vu.nl/~ast/. 

Fomos felizes em contar com a ajuda de muitas pes¬ 
soas durante o curso deste projeto. Antes de tudo, gostaría¬ 
mos de agradecer a Kees Bot por fazer a parte do leão, no 
trabalho, adequando o MINIX ao padrão e gerenciando a 
distribuição. Sem sua grande ajuda nunca teríamos feito 
tudo isso. Ele escreveu pedaços grandes do código (p. ex., a 
E/S de terminal POSix), limpou outras seções e corrigiu 
numerosos bugs que surgiram no decorrer dos anos. 
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fazer é dar um muito obrigado a todos eles. 

Várias pessoas leram partes dos originais e apresenta¬ 
ram sugestões. Gostaríamos de dedicar nosso especial agra¬ 
decimento a John Casey, Dale Grit e Frans Kaashoek. 

Na Vrije Universiteit, diversos alunos testaram a versão 
beta do CD-ROM, destacando-se: Ahmed Batou, Goran 
Dokic, Peter Gijzel, Thomer Gil, Dennis Grimbergen, Ro- 
derick Groesbeek, Wouter Haring, Guido Kollerie, Mark 
Lassche, Raymond Ris, Frans ter Borg, Alex van Ballegooy, 
Ries van der Velden, Alexander Wels e Thomas Zeeman. 
Agradecemos pelo trabalho cuidadoso e pelos relatórios de¬ 
talhados. 

ASW também gostaria de agradecer a vários dos seus 
ex-alunos, particularmente Peter W. Young, do Hampshire 
College, e Maria Isabel Sanchez e William Puddy Vargas, 
da Universidad Nacional Autónoma de Nicarágua, cujo 
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Aspectos Gerais 


Sem software, um computador é basicamente um inú¬ 
til amontoado de metal. Com software, um computador 
pode armazenar, processar e recuperar informações, exibir 
documentos de multimídia, pesquisar na Internet e envol¬ 
ver-se em muitas outras importantes atividades que justifi¬ 
cam seu valor. O software de computador pode ser dividido, 
grosso modo, em duas espe'cies: programas de sistema, que 
gerenciam a operação do computador em si, e programas 
aplicativos, que executam o trabalho que o usuário real¬ 
mente deseja. 0 programa de sistema mais fundamental é 
o sistema operacional, que controla todos os recursos do 
computador e fornece a base sobre a qual os programas 
aplicativos podem ser escritos. 

Um moderno sistema de computador consiste em um 
ou mais processadores, alguma memória principal (tam¬ 
bém conhecida como RAM — Random Access Memory, 
Memória de Acesso Aleatório), discos, impressoras, interfa¬ 
ces de rede e outros dispositivos de entrada/saída. Em suma, 
um sistema complexo. Escrever os programas que contro¬ 
lam todos esses componentes e usá-los corretamente é um 
trabalho extremamente difícil. Se cada programador tives¬ 
se de preocupar-se com o modo como as unidades de disco 
funcionam e com todas as dúzias de coisas que poderiam 
dar errado ao ler um bloco de disco, seria provável que 
muitos programas sequer pudessem ser escritos. 

Há muitos anos tornou-se bastante evidente a necessi¬ 
dade de encontrar uma maneira de isolar os programado¬ 
res da complexidade do hardware. A maneira com que isso 
se desenvolveu gradualmente foi colocar uma camada de 
software por cima do hardware básico para gerenciar todas 
as partes do sistema e oferecer ao usuário uma interface ou 
máquina virtual que é mais fácil de entender e de progra¬ 
mar. Essa camada de software é o sistema operacional e 
constitui o assunto deste livro. 

A situação é mostrada na Figura 1-1. Na parte inferior, 
está o hardware, que, em muitos casos, é composto de duas 


ou mais camadas. A camada baixa contém dispositivos fí¬ 
sicos, consistindo em circuitos integrados, cabos, fonte ali- 
mentadora, tubos de raios catódicos e dispositivos físicos 
semelhantes. Como tais elementos são construídos e como 
funcionam é assunto do engenheiro elétrico. 

Em seguida (em algumas máquinas), vem uma cama¬ 
da de software primitivo que controla diretamente esses 
dispositivos e proporciona uma interface limpa para a pró¬ 
xima camada. Esse software, chamado microprograma, 
normalmente está localizado em memória somente para 
leitura. Ele é realmente um interpretador, buscando as ins¬ 
truções de linguagem de máquina como ADD, MOVE e 
JUMP, executando-as como uma série de pequenos passos. 
Para executar uma instrução ADD, por exemplo, o micro¬ 
programa deve determinar onde os números a serem so¬ 
mados estão localizados, buscá-los, adicioná-los e arma¬ 
zenar o resultado em algum lugar. 0 conjunto de instru¬ 
ções que o microprograma interpreta define a linguagem 
de máquina, que não é realmente parte do hardware da 
máquina, mas os fabricantes de computador sempre a des¬ 
crevem em seus manuais dessa maneira, de modo que as 
pessoas pensam que ela é a “máquina” real. 

Alguns computadores, chamados de máquinas RISC 
{Reduced Instruction Set Computers), não têm um 
nível de microprogramação. Nestas máquinas, o hardware 
executa diretamente as instruções da linguagem de má¬ 
quina. Como exemplos, o Motorola 680x0 tem um nível de 
microprogramação, mas o IBM PowerPC não. 

A linguagem de máquina tipicamente tem entre 50 e 
300 instruções que, na sua maior parte, servem para mo¬ 
ver dados pela máquina, para fazer aritmética e para com¬ 
parar valores. Nessa camada, os dispositivos de entrada/ 
saída são controlados carregando valores em registradores 
especiais de dispositivo. Por exemplo, um disco pode ser 
comandado para ler carregando os valores do endereço do 
disco, o endereço de memória principal, a contagem de 
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Figura 1-1 Um sistema de computador consiste em hardware, em programas de sistema e em programas aplicativos. 


bytes e a instrução (rkad ou writk) em seus registradores. 
Na prática, muitos parâmetros a mais são necessários e o 
resultado retornado pela unidade depois de uma operação 
é altamente complexo. Além disso, para muitos dispositi¬ 
vos de E/S, a temporizanação desempenha um papel im¬ 
portante na programação. 

Uma importante função do sistema operacional é es¬ 
conder toda essa complexidade e oferecer um conjunto mais 
conveniente de instruções para o programador trabalhar. 
Por exemplo, READ BLOCK FROM FILE é conceitualmente 
mais simples que ter de preocupar-se com os detalhes do 
movimento das cabeças de disco, esperar que elas abaixem 
e assim por diante. 

Por cima do sistema operacional está o resto do softwa¬ 
re de sistema. Aqui encontramos o interpretador de coman¬ 
dos ( shell ), sistemas de janelas, compiladores, editores e 
programas independentes de aplicação semelhantes. É 
importante saber que esses programas definitivamente não 
são parte do sistema operacional, mesmo que eles tipica¬ 
mente sej am fornecidos pelo fabricante do computador. Esse 
é um ponto crucial, mas sutil. 0 sistema operacional é aque¬ 
la porção do software que executa no modo kemel ou no 
modo de supervisor. Ele é protegido do usuário pelo har¬ 
dware (ignorando por enquanto os microprocessadores 
mais antigos que não tinham nenhuma proteção de hard¬ 
ware). Os compiladores e editores executam no modo de 
usuário. Se um usuário não gosta de um compilador par¬ 
ticular, ele é livre para escrever seu próprio compilador se 
preferir; mas ele não é livre para escrever seu próprio ma¬ 
nipulador de interrupções de disco, que é parte do sistema 
operacional e normalmente é protegido por hardware con¬ 
tra tentativas dos usuários de modificá-lo. 

Por fim, acima dos programas de sistema vêm os pro¬ 
gramas aplicativos. Esses programas são comprados ou são 
escritos pelos usuários para resolver seus problemas parti¬ 
culares, como processadores de texto, planilhas eletrôni¬ 
cas, programas de cálculo de engenharia ou jogos. 


1.1 O QUE É UM SISTEMA 
OPERACIONAL? 

A maioria dos usuários de computador teve alguma 
experiência com um sistema operacional, embora seja di¬ 
fícil precisar exatamente o que é um sistema operacional. 
Parte do problema é que os sistemas operacionais execu¬ 
tam basicamente duas funções não-relacionadas e depen¬ 
dendo de quem está falando, você ouve mais uma coisa ou 
outra. Vamos examinar as duas agora. 

1.1.1 O Sistema Operacional como 
uma Máquina Estendida 

Como mencionado anteriormente, a arquitetura (con¬ 
junto de instruções, organização da memória, E/S e estru¬ 
tura de barramento) da maior parte dos computadores no 
nível da linguagem de máquina é primitiva e desajeitada 
para programar, especialmente para entrada/saída. Para 
tornar essa idéia mais palpável, veja como a E/S de disque¬ 
te é feita usando o chip controlador NEC PD765 (ou equi¬ 
valente), utilizado na maioria dos computadores pessoais. 

0 PD765 tem 16 comandos, cada um especificado car¬ 
regando-se entre 1 e 9 bytes em um registrador de disposi¬ 
tivo. Esses comandos são para ler e para gravar dados, para 
mover o braço de disco e para formatar trilhas, assim como 
para inicializar, avaliar, ressetar e recalibrar a controlado¬ 
ra e as unidades. 

Os comandos mais básicos são READ e write, cada um 
deles requerendo 13 parâmetros, compactados em 9 bytes. 
Tais parâmetros especificam itens como o endereço do blo¬ 
co de disco a ser lido, o número de setores por trilha, o 
modo de gravação utilizado no meio físico, o tamanho do 
intervalo entre setores e o que fazer com uma marca de 
endereço de dados excluídos. Se você não entende este pa¬ 
lavrório, não se preocupe; é essa exatamente a questão — 
é tudo muito esotérico. Quando a operação é completada, 
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o chip controlador retorna 23 campos de status e erro com¬ 
pactados em 7 bytes. Como se isso não fosse suficiente, o 
programador do disquete também deve estar constantemen¬ 
te ciente sobre se o motor está ligado ou desligado. Se o 
motor estiver desligado, ele deve ser ligado (com uma de¬ 
mora longa de inicialização) antes de os dados poderem 
ser lidos ou gravados. Mas o motor não pode permanecer 
ligado por muito tempo, senão o disquete irá desgastar-se. 

O programador assim é forçado a negociar entre a demora 
na inicialização e o desgaste dos disquetes (e a perda dos 
dados neles). 

Sem entrar nos detalhes reais, deve estar claro que o 
programador médio provavelmente não quer ficar muito 
intimamente envolvido com a programação de disquetes 
(nem discos rígidos, que são igualmente complexos, ape¬ 
sar de bem diferentes). Em vez disso, o que o programador 
quer é uma abstração de ordem superior mais simples de 
lidar. No caso dos discos, uma abstração típica seria que o 
disco contém uma coleção de nomes de arquivos. Cada ar¬ 
quivo pode ser aberto para leitura ou gravação, então lido 
ou gravado e finalmente fechado. Detalhes como se a gra¬ 
vação deve ou não usar modulação de freqüência modifi¬ 
cada e qual é o estado atual do motor não devem aparecer 
na abstração apresentada ao usuário. 

O programa que esconde do programador a verdade 
sobre o hardware e apresenta uma bela e simples visão de 
nomes de arquivos que podem ser lidos e gravados é, natu¬ 
ralmente, o sistema operacional. Assim como o sistema 
operacional esconde do programador o hardware de disco 
e apresenta uma interface orientada para arquivo mais sim¬ 
ples, ele também oculta muitas coisas desagradáveis rela¬ 
cionadas com interrupções, temporizadores, gerenciamento 
de memória e outros recursos de baixo nível. Em cada caso, 
a abstração oferecida pelo sistema operacional é mais sim¬ 
ples e mais fácil de utilizar que o hardware subjacente. 

Deste ponto de vista, a função do sistema operacional é 
apresentar ao usuário o equivalente de uma máquina es¬ 
tendida ou máquina virtual que é mais fácil de progra¬ 
mar que o hardware subjacente. O modo como o sistema 
operacional alcança esse objetivo é uma longa história, que 
estudaremos em detalhe ao longo de todo este livro. 

1.1.2 O Sistema Operacional como um 
Gerenciador de Recursos 

O conceito do sistema operacional como principalmente 
oferecendo aos seus usuários uma interface conveniente é 
uma visão top-down' . Uma visão alternativa, botton-up ", 
sustenta que o sistema operacional está aí para gerenciar 
todas as partes de um sistema complexo. Os computadores 
modernos consistem em processadores, memórias, tempo¬ 
rizadores, discos, mouses, interfaces de rede, impressoras a 
laser e uma ampla variedade de outros dispositivos. Na vi¬ 
são alternativa, o trabalho do sistema operacional é ofere- 


*N. de T. Top-down: visão de cima para baixo. 
"N. de T. Botton-up: visão de baixo para cima. 


cer uma alocação ordenada e controlada dos processado¬ 
res, das memórias e dos dispositivos de E/S entre os vários 
programas que competem por eles. 

Imagine o que aconteceria se três programas que exe¬ 
cutam em algum computador tentassem imprimir simul¬ 
taneamente na mesma impressora. As primeiras poucas li¬ 
nhas de impressão talvez sejam do programa 1, as poucas 
linhas seguintes do programa 2, então algumas do progra¬ 
ma 3, etc. O resultado seria o caos. O sistema operacional 
pode trazer ordem a esse caos potencial armazenando toda 
a saída destinada para a impressora no disco. Quando um 
programa tiver terminado, o sistema operacional pode, 
então, copiar sua saída a partir do arquivo de disco onde 
ela foi armazenada para a impressora, enquanto, ao mes¬ 
mo tempo, o outro programa pode continuar a gerar mais 
saída, ignorando o fato de que a saída realmente não está 
indo para a impressora (ainda). 

Quando um computador (ou uma rede) tem múltiplos 
usuários, a necessidade de gerenciar e de proteger a me¬ 
mória, os dispositivos de E/S e outros recursos é ainda maior 
uma vez que os usuários talvez interfiram um com outro. 
Além disso, os usuários freqüentemente necessitam não só 
compartilhar hardware, mas também as informações (ar¬ 
quivos, bases de dados, etc.). Em resumo, essa visão do sis¬ 
tema operacional sustenta que sua tarefa primária é mo¬ 
nitorar quem está utilizando qual recurso, atender requi¬ 
sições de recurso, medir a utilização dos recursos e medir 
as requisições conflitantes de diferentes programas e usuá¬ 
rios. 


1.2 A HISTÓRIA DOS SISTEMAS 
OPERACIONAIS 

Os sistemas operacionais vêm desenvolvendo-se ao lon¬ 
go dos anos. Nas próximas seções, veremos resumidamen¬ 
te esse desenvolvimento. Uma vez que os sistemas operaci¬ 
onais historicamente estiveram intimamente associados à 
arquitetura dos computadores nos quais eles rodam, exa¬ 
minaremos as sucessivas gerações de computadores para 
ver como eram seus sistemas operacionais. Tal relaciona¬ 
mento das gerações de sistemas operacionais com as gera¬ 
ções de computadores é grosseiro, mas oferece uma base 
que de outra forma não teríamos. 

0 primeiro computador digital verdadeiro foi projetado 
pelo matemático inglês Charles Babbage (1792-1871). 
Embora Babbage tenha gasto a maior parte de sua vida e 
sua fortuna tentando construir seu "motor analítico", ele 
nunca conseguiu fazê-lo funcionar adequadamente por¬ 
que a coisa era puramente mecânica e a tecnologia do seu 
tempo não podia produzir as necessárias rodas e engrena¬ 
gens de alta precisão de que ele precisava. É desnecessário 
dizer, mas o motor analítico não tinha um sistema opera¬ 
cional. 

Como um interessante dado histórico, Babbage sabia que 
precisaria de um software para seu motor analítico, assim 
ele contratou uma jovem mulher, chamada Ada Lovelace, 
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que era filha do famoso poeta britânico Lord Byron. como 
primeiro programador do mundo. 0 nome da linguagem 
de programação Ada® foi criado em sua homenagem. 

1.2.1 A Primeira Geração (1945-55): 
Válvulas e Painéis de Conectores 

Depois dos esforços malsucedidos de Babbage, pouco 
progresso foi alcançado na construção de computadores 
digitais até a II Guerra Mundial. Em meados da década de 
40, Howard Aiken, de Harvard, John von Neumann, do Ins¬ 
tituto de Estudos Avançados de Princeton, J. Presper Eckert 
e William Mauchley, da Universidade da Pensilvânia. e 
Konrad Zuse, na Alemanha, entre outros, tiveram sucesso 
na construção de máquinas de cálculo utilizando válvu¬ 
las. Essas máquinas eram enormes, ocupando salas intei¬ 
ras com dezenas de milhares de válvulas, e eram muito 
mais lentas que as mais simples calculadoras de hoje. 

Naqueles tempos, um único grupo de pessoas projetava, 
construía, programava, operava e mantinha cada máqui¬ 
na. Toda a programação era feita em linguagem de máqui¬ 
na pura, freqüentemente ligando com fios painéis de co¬ 
nectores para controlar as funções básicas da máquina. As 
linguagens de programação eram desconhecidas (nem 
mesmo a linguagem assembly) e ninguém nunca tinha 
ouvido falar de sistemas operacionais. O modo normal de 
operação era o programador reservar um período de tempo 
na folha de reserva na parede, depois descer até o lugar da 
máquina, inserir suas conexões no computador e gastar 
algumas horas esperando que nenhuma das aproximada¬ 
mente 20.000 válvulas queimasse durante a execução. Pra¬ 
ticamente todos os problemas eram simples cálculos nu¬ 
méricos, tais como gerar tabelas de senos e de co-senos. 

No início da década de 50, a rotina havia melhorado 
um pouco com a introdução dos cartões perfurados. Agora 
era possível gravar programas em cartões e lê-los, em vez 
de usar cabos e conectores; fora isso, o procedimento era o 
mesmo. 

1.2.2 A Segunda Geração (1955-65): 
Transistores e Sistemas de Lote 

A introdução do transistor, em meados da década de 50, 
mudou o quadro radicalmente. Os computadores torna¬ 
ram-se confiáveis o bastante para serem fabricados e ven¬ 
didos para clientes com a expectativa de que continuariam 
a funcionar por tempo suficiente para realizar algum tra¬ 
balho útil. Pela primeira vez, havia uma separação clara 
entre projetistas, construtores, operadores, programadores 
e o pessoal da manutenção. 

Essas máquinas eram guardadas em salas especiais com 
ar-condicionado e equipes de operadores profissionais para 
mantê-las funcionando. Somente as grandes corporações 
ou importantes órgãos do governo ou universidades podi¬ 
am ter recursos para arcar com seu preço, na casa dos mi¬ 
lhões de dólares. Para executar um job (i. e., um progra¬ 
ma ou um conjunto de programas), um programador pri¬ 


meiro escrevia o programa em papel (em FORTRAN ou as¬ 
sembly), e então o transformava em cartões perfurados. 
Ele então levava o conjunto de cartões para a sala de en¬ 
trada e entregava-os a um dos operadores. 

Quando o computador acabava o job que estava execu¬ 
tando. um operador ia até a impressora, removia a saída e 
a levava para a sala de saída, para que o programador pu¬ 
desse recolhê-la mais tarde. Então, o operador pegaria um 
dos conjuntos de cartões que haviam sido trazidos da sala 
de entrada e os inseria na máquina para leitura. Se o com¬ 
pilador FORTRAN fosse necessário, o operador teria que 
pegá-lo em um gabinete de arquivos e inseri-lo para leitu¬ 
ra. Muito tempo de máquina era desperdiçado enquanto 
os operadores andavam em volta do computador. 

Dado o alto custo do equipamento, não é de surpreen¬ 
der que as pessoas rapidamente começassem a procurar 
maneiras de reduzir o tempo desperdiçado. A solução ge¬ 
ralmente adotada era o sistema de processamento em 
lotes (ou batch system). A idéia subjacente a essa solução 
era colecionar uma bandeja completa de jobs na sala de 
entrada e então lê-los sobre uma fita magnética utilizando 
um computador pequeno (relativamente) e barato como o 
IBM 1401, que era muito bom para ler cartões, para copiar 
fitas e para imprimir a saída, mas péssimo em cálculos 
numéricos. Outras máquinas muito mais caras, como o 
IBM 7094, eram utilizadas para a computação de fato. Essa 
situação é mostrada na Figura 1-2. 

Depois de cerca de uma hora de coleta de um lote de 
jobs. a fita era rebobinada e levada à sala de máquinas, 
onde era montada em uma unidade de fita. O operador 
então, carregava um programa especial (0 antepassado do 
sistema operacional de hoje), que lia 0 primeiro job da fita 
e executava. A saída era gravada em uma segunda fita em 
vez de ser impressa. Depois que cada job acabava, 0 siste¬ 
ma operacional automaticamente lia 0 próximo job da fita 
e começava a executá-lo. Quando 0 lote inteiro estava com¬ 
pleto, 0 operador removia as fitas de entrada e saída, subs¬ 
tituía a fita de entrada pelo próximo lote e levava a fita de 
saída para um 1401 imprimir ojfline (i. e., não-conectado 
ao computador principal). 

A estrutura de um típico job de entrada é mostrada na 
Figura 1-3. Ela começava com um cartão $J0B, especifi¬ 
cando 0 tempo máximo de execução em minutos, 0 nú¬ 
mero de conta a ser carregado e 0 nome do programador. 
Então, vinha um cartão SFORTRAN, instruindo 0 sistema 
operacional a carregar 0 compilador FORTRAN da fita de 
sistema, 0 qual era seguido pelo programa a ser compilado 
e então um cartão $LOAD, orientando 0 sistema operacio¬ 
nal a carregar 0 programa objeto recém-compilado. (Pro¬ 
gramas compilados freqüentemente eram escritos em fitas 
virgens e tinham de ser carregados explicitamente.) Em 
seguida, vinha 0 cartão $RUN, instruindo 0 sistema opera¬ 
cional a executar 0 programa com os dados que 0 segui¬ 
am. Finalmente, 0 cartão $END marcava 0 fim do job. Es¬ 
ses cartões primitivos de controle foram os precursores das 
linguagens modernas de controle de jobs e interpretadores 
de comando. 
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Figura 1-2 Um sistema de lote primitivo, (a) Programadores trazem os cartões para o 1401. (b) 0 1401 lèosyofoem lote na fita. (c) 
O operador leva a fita de entrada para o 7094. (d) O 7094 realiza a computação, (e) O operador leva a fita de saída para o 1401. (f) O 
1401 imprime a saída. 


Grandes computadores de segunda geração eram utili¬ 
zados principalmente para cálculos científicos de engenha¬ 
ria, tal como resolver equações diferenciais parciais. Eles 
em grande parte eram programados em FORTRAN e lin¬ 
guagem assembler. Sistemas operacionais típicos eram o 
FMS (o Fortran Monitor System) e o IBSYS, sistema ope¬ 
racional da IBM para o 7094. 

1.2.3 A Terceira Geração (1965- 
1980): CIs e Multiprogramação 

No início da década de 60, a maioria dos fabricantes de 
computadores tinha duas linhas de produto distintas e to¬ 
talmente incompatíveis. De um lado, havia os computado¬ 
res científicos de grande escala, baseados em palavras, como 


0 7094, que eram utilizados para cálculos numéricos em 
Ciência e em Engenharia. Por outro lado, havia os compu¬ 
tadores comerciais, baseados em caracteres, como 0 1401, 
que eram amplamente utilizados para classificar e para 
imprimir fitas para bancos e para companhias de seguro. 

Desenvolver e manter duas linhas completamente dife¬ 
rentes de produtos era uma proposta cara para os fabrican¬ 
tes. Além disso, muitos novos clientes necessitavam, inici¬ 
almente, de uma máquina pequena. Mais tarde cresciam e 
queriam uma máquina maior que executasse todos os seus 
antigos programas, só que mais rapidamente. 

A IBM tentou resolver ambos esses problemas em uma 
única tacada introduzindo 0 System/ 360 . O 360 era uma 
série de máquinas compatíveis ao nível de software que va¬ 
riavam desde a capacidade de um 1401 até um muito mais 



Figura 1-3 A estrutura de um típico job do FMS. 
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poderoso que o 7094. As máquinas diferiam só no preço e 
no desempenho (memória máxima, velocidade de proces¬ 
sador, número de dispositivos de E/S permitidos, etc.). Como 
todas as máquinas tinham a mesma arquitetura e conjun¬ 
to de instruções, programas escritos para uma máquina 
podiam executar em todas as outras, pelo menos na teoria. 
Além disso, o 360 foi projetado para manipular cálculos 
tanto científicos como comerciais. Assim, uma única fa¬ 
mília de máquinas podia satisfazer as necessidades de to¬ 
dos clientes. Nos anos seguintes, a IBM lançou sucessores 
compatíveis com a linha 360, usando tecnologia mais 
moderna, conhecidos como as séries 370,4300,3080 e 3090. 

O 36o era a primeira linha importante de computado¬ 
res usando Circuitos Integrados (CIs) — de pequena esca¬ 
la —, proporcionando assim uma vantagem importante 
de preço/desempenho sobre as máquinas de segunda gera¬ 
ção, que eram baseadas em transistores como componen¬ 
tes. Ele foi um êxito imediato e a idéia de uma família de 
computadores compatíveis logo foi adotada por todos os 
outros fabricantes importantes. Os descendentes dessas 
máquinas ainda estão em uso hoje em centros de compu¬ 
tação espalhados por aí, mas seu uso está declinando rapi¬ 
damente. 

A maior força da idéia de “uma família” era ao mesmo 
tempo sua maior fraqueza. A intenção era que todo softwa¬ 
re, incluindo 0 sistema operacional, tinha de trabalhar em 
todos os modelos. Ele tinha de executar em sistemas pe¬ 
quenos, que freqüentemente apenas substituíam os 1401 
para copiar cartões em fita, e em sistemas muito grandes, 
que freqüentemente substituíam os 7094 para fazer previ¬ 
são do tempo e outros cálculos pesados. Ele tinha de ser 
bom em sistemas com poucos periféricos e em sistemas com 
muitos periféricos. Ele tinha de funcionar em ambientes 
comerciais e em ambientes científicos. Acima de tudo, ele 
tinha de ser eficiente para todos esses diferentes usos. 

Não havia como a IBM (ou qualquer outra pessoa) con¬ 
seguir escrever um software para atender a todos esses re¬ 
quisitos contraditórios. O resultado era um sistema opera¬ 
cional extraordinariamente complexo e grande, provavel¬ 
mente duas a três ordens de magnitude maior que 0 FMS. 
Ele consistia em milhões de linhas de linguagem assem- 
bler escritas por milhares de programadores com milhares 
e milhares de bugs *, que necessitavam de um contínuo flu¬ 
xo de novas versões na tentativa de corrigi-los. Cada nova 
versão corrigia alguns bugs e introduzia novos, então 0 
número de bugs provavelmente permanecia constante com 
0 tempo. 

Um dos projetistas do OS/ 360 , Fred Brooks, posteriormen- 
te escreveu um livro incisivo e perspicaz (Brooks, 1975) 
descrevendo suas experiências com 0 OS/ 360 . Embora seja 
impossível resumir 0 livro aqui, basta dizer que a capa 


'N. de T. Bug: um erro na codificação ou na lógica que faz com que 
um programa não funcione corretamente ou que produza resultados 
incorretos. 


mostra uma horda de bestas pré-históricas atoladas em uma 
poça de petróleo. A capa do livro de Silberschatz e Galvin 
(1994) faz uma comparação semelhante. 

Apesar do seu enorme tamanho e de seus problemas, 0 
OS /360 e os sistemas operacionais semelhantes de terceira 
geração produzidos por outros fabricantes de computador 
realmente satisfizeram a maioria de seus clientes razoa¬ 
velmente bem. Eles também popularizaram várias técni¬ 
cas-chave ausentes em sistemas operacionais de segunda 
geração. Provavelmente a mais importante destas era a 
\ multiprogramação. No 7094, quando 0 job atual fazia 
uma pausa para esperar uma fita ou outra operação de 
E/S completar-se, a CPU simplesmente ficava desocupada 
até 0 término da operação. Com cálculos científicos que 
exigem intensamente a CPU, as operações de E/S são pou¬ 
co freqüentes, de modo que esse tempo desperdiçado não é 
significativo. Com processamento comercial de dados, 0 
tempo de espera de E/S freqüentemente pode ser 80 ou 90% 
do tempo total. Então, algo devia ser feito para evitar ter a 
CPU desocupada durante tanto tempo. 

A solução desenvolvida foi dividir a memória em várias 
partições, com um job diferente em cada partição, como 
mostrado na Figura 1-4. Enquanto um job estava esperan¬ 
do uma operação de E/S completar-se, outro job podia usar 
a CPU. Se um número suficiente de jobs pudesse ser man¬ 
tido na memória principal de uma vez, a CPU poderia ficar 
ocupada quase 100% do tempo. Ter múltiplos jobs em me¬ 
mória de uma vez requer hardware especial para evitar que 
um job prejudique outro, mas 0 360 e outros sistemas de 
terceira geração estavam equipados com esse hardware. 

Outro importante recurso apresentado nos sistemas 
operacionais de terceira geração era a capacidade de ler 
jobs de cartões para 0 disco logo que eles eram trazidos 
para a sala de computador. Então, sempre que um job em 
execução acabava, 0 sistema operacional podia carregar 
um novo job do disco na partição agora vazia e executá-lo. 
Essa técnica é chamada spooling (de Simultaneous Peri- 
pheral Operation On Line — Operação Periférica Simul¬ 
tânea On Line) e era também utilizada para saída. Com 0 
spooling, os 1401 não eram mais necessários e acabava 
grande parte do trabalho de carregamento de fitas. 

Embora os sistemas operacionais de terceira geração 
servissem bem para grandes cálculos científicos e para apli¬ 
cações comerciais com grande volume de processamento 
de dados, eles eram ainda basicamente sistemas de lote. 
Muitos programadores sentiam falta das máquinas de pri¬ 
meira geração quando tinham a máquina toda para si por 
algumas horas e, assim, podiam depurar seus programas 
rapidamente. Com os sistemas de terceira geração, 0 tem¬ 
po entre submeter um job e receber a saída era freqüente¬ 
mente de várias horas, então uma única vírgula malcolo- 
cada podia causar uma falha na compilação e 0 progra¬ 
mador perdia metade de um dia. 

Essa necessidade de tempo de resposta rápido preparou 
0 caminho para 0 compartilhamento de tempo, uma 
variante da multiprogramação na qual cada usuário ti¬ 
nha um terminal on-line. Em um sistema de tempo com- 
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de memória 


Figura 1-4 Um sistema de multiprogramação com XKsjobs em memória. 


partilhado, se 20 usuários efetuavam logon * e 17 deles es¬ 
tavam pensando, conversando ou bebendo café, a CPU po¬ 
dia estar alocada para os três jobs que requeriam processa¬ 
mento. Como as pessoas que depuram programas normal¬ 
mente utilizam comandos curtos (p. ex., compilar um pro¬ 
cedimento de cinco páginas) em vez de longos (p. ex., clas¬ 
sificar um arquivo de um milhão de registros), o compu¬ 
tador pode oferecer serviço rápido e interativo para alguns 
usuários e talvez também trabalhar com grandes traba¬ 
lhos em lote em segundo plano quando a CPU está desocu¬ 
pada. Embora o primeiro sistema de tempo compartilhado 
sério (CTSS) tenha sido desenvolvido no M.I.T. em um 7094 
especialmente modificado (Corbato et ai, 1962), o com¬ 
partilhamento de tempo não se popularizou realmente até 
que a necessária proteção de hardware se tornasse comum 
durante a terceira geração. 

Depois do êxito do sistema CTSS, o MIT, a Bell Labs e a 
General Electric (na época, um importante fabricante de 
computadores) decidiram dedicar-se ao desenvolvimento 
de um “ Computer utility’”” , uma máquina que suportaria 
centenas de usuários de tempo compartilhado simultâne¬ 
os. Seu modelo era o sistema de distribuição de eletricida¬ 
de — quando você precisa de energia elétrica, basta sim¬ 
plesmente introduzir um plugue na tomada da parede e, 
dentro do possível, toda a energia de que você precisa esta¬ 
rá disponível. Os projetistas desse sistema, conhecido como 
MULTICS {MULTiplexedInformation and Computing Ser¬ 
vice — Serviço de Computação e Informação Multiplexa- 
do), vislumbraram uma máquina para oferecer enorme 
poder de cálculo a todos em Boston. A idéia de que máqui¬ 
nas muito mais poderosas do que seu GE-645 seriam ven¬ 
didas como computadores pessoais por alguns milhares de 
dólares só 30 anos mais tarde era pura ficção científica na 
época. 


"N. de R. Logon : Processo de identificação do usuário para o computa¬ 
dor, depois que entra em contato com ele através de uma linha de co¬ 
municação. Também chamado de login {Dicionário de Informáti¬ 
ca. Microsoft Press. Rio de Janeiro, Editora Campus, 1998). 

"N. de R. Utility neste caso tem o sentido de um serviço público, indi¬ 
cando um recurso computacional amplamente disponível. 


Para encurtar essa longa história, o mixtics introdu¬ 
ziu muitas idéias seminais na literatura sobre computado¬ 
res, mas construí-lo foi algo muito mais difícil do que o 
esperado. A Bell Labs retirou-se do projeto e a General Elec¬ 
tric desistiu completamente do negócio de computadores. 
Por fim, o MULTICS rodou suficientemente bem para ser 
utilizado em um ambiente de produção no MIT e dúzias 
de outros lugares, mas o conceito de um Computer utility 
virou um fiasco à medida que os preços dos computadores 
despencaram. Ainda assim, o MULTICS teve uma influência 
enorme em sistemas subseqüentes. Ele é descrito em Cor¬ 
bato e colaboradores, 1972, Corbato e Vyssotsky, 1965, Da- 
ley e Dennis, 1968, Organick, 1972, e Saltzer, 1974. 

Outro importante desenvolvimento durante a terceira 
geração foi 0 crescimento fenomenal dos minicomputado¬ 
res, começando com 0 PDP-1 da DEC em 1961 . O PDP-1 
tinha só 4K de palavras de 18 bits, mas a US$ 120.000 por 
máquina (menos que 5% do preço de um 7094) venderam 
como pãozinho quente de padaria. Para certas espécies de 
trabalhos não-numéricos, era quase tão rápido quanto os 
7094 e deu origem a toda uma nova indústria, tendo sido 
rapidamente seguido por uma série de outros PDP (mas, 
ao contrário da família IBM, eram todos incompatíveis), 
culminando no PDP-11. 

Um dos cientistas de computação da Bell Labs que ti¬ 
nha trabalhado no projeto do MULTICS, Ken Thompson, 
subseqüentemente descobriu um pequeno microcomputa¬ 
dor PDP-7 que ninguém estava usando e começou a escre¬ 
ver uma versão simplificada monousuária do MULTICS. Esse 
trabalho mais tarde desenvolveu-se no sistema operacio¬ 
nal UNIX®, que se tornou popular no mundo acadêmico, 
entre órgãos do governo e entre muitas empresas. 

A história do UNIX foi bem contada em outros textos (p. 
ex., Salus, 1994). Basta dizer que como 0 código-fonte es¬ 
tava amplamente disponível, várias organizações desenvol¬ 
veram suas próprias versões (incompatíveis), que levaram 
ao caos. Para tornar possível escrever programas que podi¬ 
am executar em qualquer sistema UNIX, 0 IEEE desenvol¬ 
veu um padrão para 0 UNIX, chamado POSIX, que a maio¬ 
ria das versões do UNIX agora suporta. 0 posix define uma 
interface mínima de chamadas de sistema que sistemas 
compatíveis com 0 UNIX devem suportar. Aliás, alguns ou¬ 
tros sistemas operacionais agora também suportam a in¬ 
terface POSIX. 
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1.2.4 A Quarta Geração (1980-hoje): 
Computadores Pessoais 

0 desenvolvimento dos circuitos LSI (Large Scale Inte¬ 
gra tion — integração em larga escala), chips contendo mi¬ 
lhares de transistores por centímetro quadrado de silício, 
foi o alvorecer da era do computador pessoal. Em termos 
de arquitetura, tais computadores não eram tão diferentes 
dos minicomputadores da classe PDP-11, mas, em termos 
de preço, certamente eram diferentes. Assim como o mini¬ 
computador possibilitou que um departamento em uma 
empresa ou em uma universidade tivesse seu próprio com¬ 
putador, o microprocessador tornou possível que uma pes¬ 
soa tivesse seu próprio computador pessoal. Os computa¬ 
dores pessoais mais poderosos utilizados em negócios, em 
universidades e em órgãos do governo normalmente são 
chamados de estações de trabalho, mas na realidade são 
apenas computadores pessoais de maior porte, normalmen¬ 
te conectados por uma rede. 

A ampla disponibilidade do poder de computação, es¬ 
pecialmente a computação altamente interativa, normal¬ 
mente com excelentes gráficos, levou ao crescimento de 
uma importante indústria de produção de software para 
computadores pessoais. Grande parte desse software tinha 
uma interface amigável, ou seja, projetada para usuários 
que não só ignoravam tudo sobre computadores como tam¬ 
bém não tinham nenhuma intenção de aprender. Essa era 
certamente uma mudança importante do OS/360, cuja lin¬ 
guagem de controle, JCL (Job ControlLanguage- lingua¬ 
gem de controle de trabalhos), era tão complexa que livros 
inteiros foram escritos sobre ela (p. ex., Cadow, 1970). 

Dois sistemas operacionais inicialmente dominaram a 
cena do computador pessoal e da estação de trabalho: o 
MS-DOS da Microsoft e o UNIX. O MS-DOS era amplamente 
utilizado no IBM PC e em outras máquinas que empregam 
a CPU Intel 8088 e seus sucessores, 80286, 80386 e 80486 
(que referiremos doravante como 286, 386 e 486, respecti¬ 
vamente) e mais tarde o Pentium e o Pentium PRO. Em¬ 
bora a versão inicial do MS-DOS fosse relativamente primi¬ 
tiva, as posteriores incluíram recursos mais avançados, in¬ 
clusive muitos tomados do UNIX. O sucessor da Microsoft 
para o MS-DOS, o WINDOWS, originalmente rodava por cima 
do MS-DOS (i. e., era mais como um shell do que um siste¬ 
ma operacional verdadeiro), mas, em 1995, foi lançada 
uma versão“independente" do Windows, o Windows 95 ®, 
de modo que 0 MS-DOS não é mais necessário para suportá- 
lo. Outro sistema operacional da Microsoft é 0 WINDOWS 
nt, compatível com 0 Windows 95 até certo nível, mas que 
foi completamente reescrito internamente. 

O outro importante concorrente é 0 UNIX, que é domi¬ 
nante em estações de trabalho e em outros computadores 
topo de linha, como servidores de rede, e especialmente 
popular em máquinas equipadas com chips RISC de alto 
desempenho. Essas máquinas normalmente têm 0 poder 
de computação de um minicomputador, ainda que dedi¬ 
cados para um único usuário, então é lógico que sejam 


equipadas com um sistema operacional originalmente pro¬ 
jetado para minicomputadores, 0 UNIX. 

Um desenvolvimento interessante que começou durante 
meados da década de 80 é 0 crescimento de redes de com¬ 
putadores pessoais executando sistemas operacionais de 
rede e sistemas operacionais distribuídos (Tanen- 
baum, 1995). Em um sistema operacional de rede, os usu¬ 
ários estão cientes da existência de múltiplos computado¬ 
res e podem conectar-se a máquinas remotas e copiar ar¬ 
quivos de uma máquina para outra. Cada máquina exe¬ 
cuta localmente 0 sistema operacional e tem seu próprio 
usuário local (ou usuários). 

Os sistemas operacionais de rede não são fundamen¬ 
talmente diferentes dos sistemas operacionais monoproces- 
sador. Eles obviamente necessitam de uma interface de rede 
e de algum software de baixo nível para controlá-la, assim 
como programas para permitir conexões remotas e acesso 
a arquivos remotos. Entretanto, tais adições não mudam 
essencialmente a estrutura do sistema operacional. 

Um sistema operacional distribuído, ao contrário, é 
aquele que aparece para seus usuários como um sistema 
monoprocessado tradicional, mesmo que realmente seja 
composto de múltiplos processadores. Os usuários não sa¬ 
bem onde seus programas estão sendo executados nem onde 
seus arquivos estão localizados; tudo isso deve ser manipu¬ 
lado de forma automática e eficiente pelo sistema operaci¬ 
onal. 

Verdadeiros sistemas operacionais distribuídos reque¬ 
rem mais do que apenas adicionar uma pequena porção 
de código a um sistema operacional monoprocessado, por¬ 
que os sistemas centralizados e distribuídos diferem signi¬ 
ficativamente. Os sistemas distribuídos, por exemplo, com 
freqüência permitem que os aplicativos executem em vári¬ 
os processadores ao mesmo tempo; assim eles requerem 
um algoritmo de agendamento de processador mais com¬ 
plexo a fim de otimizar a quantidade de paralelismo. 

A demora de comunicação dentro de uma rede segui¬ 
damente significa que esses (e outros) algoritmos devem 
executar com informações desatualizadas, incompletas ou 
até incorretas. Essa situação é radicalmente diferente de 
um sistema monoprocessado em que 0 sistema operacio¬ 
nal tem informações completas sobre 0 estado do sistema. 

1.2.5 A História do MINIX 

Quando 0 UNIX era jovem (Versão 6 ), 0 código-fonte 
estava amplamente disponível, sob licença da AT&T, e era 
muito estudado. John Lions, da Universidade New' South 
Wales, na Austrália, escreveu uma pequena brochura que 
descrevia sua operação, linha por linha (Lions, 1996). Essa 
publicação era utilizada (com permissão de AT&T) como 
referência em muitos cursos universitários sobre sistemas 
operacionais. 

Quando a AT&T lançou a Versão 7, começou-se a per¬ 
ceber que 0 UNIX era um produto comercial valioso, e as¬ 
sim ela lançou essa versão com uma licença proibindo que 
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o código-fonte fosse estudado em cursos, para evitar pôr 
em risco seu status de segredo de negócio. Muitas universi¬ 
dades tiveram de conformar-se em simplesmente acabar 
com o estudo de UNIX e ensinar só teoria. 

Infelizmente, ensinar só teoria deixa o aluno com uma 
visão equivocada do que é realmente um sistema operaci¬ 
onal. Os temas teóricos que normalmente são abordados 
detalhadamente em cursos e em livros sobre sistemas ope¬ 
racionais, como algoritmos de agendamento, não são re¬ 
almente tão importantes na prática. Os assuntos realmen¬ 
te relevantes, como E/S e sistemas de arquivos, geralmente 
são negligenciados, pois há pouca teoria sobre eles. 

Para corrigir essa situação, um dos autores deste livro 
(Tanenbaum) decidiu escrever um novo sistema operacio¬ 
nal a partir do zero, que seria compatível com UNIX do ponto 
de vista do usuário, mas completamente diferente interior- 
mente. Por não usar sequer uma linha do código da AT&T, 
esse sistema evita as restrições de licenciamento, assim ele 
pode ser utilizado para estudo individual ou em classe. Desta 
maneira, os leitores podem dissecar um sistema operacio¬ 
nal real para ver o que há por dentro, assim como estudan¬ 
tes de Biologia dissecam rãs em laboratório. O nome MINTX 
significa mini-uxix pois ele é tão pequeno que mesmo um 
não-especialista pode entender seu funcionamento. 

Além da vantagem de eliminar os problemas legais, o 
MINIX tem outra vantagem sobre o UNIX. Foi escrito uma 
década depois do UNIX e estruturado de maneira mais mo¬ 
dular. 0 sistema de arquivos do MINIX, por exemplo, não é 
absolutamente parte do sistema operacional, mas roda 
como um programa de usuário. Outra diferença: enquan¬ 
to o UNIX foi projetado para ser eficiente, o MINIX o foi para 
ser legível (se é que alguém pode falar de qualquer progra¬ 
ma com centenas de páginas como sendo legível). O códi¬ 
go do MINIX, por exemplo, tem milhares de comentários. 

O MINIX originalmente foi projetado para ter compati¬ 
bilidade com a Versão 7 (V7) do UNIX, a qual era utilizada 
como modelo por causa de sua simplicidade e elegância. 
Às vezes, diz-se que a Versão 7 não era só uma melhora em 
relação a todos os seus antecessores, como também sobre 
todos seus sucessores. Com o advento do POSix, o mintx co¬ 
meçou a desenvolver-se em direção ao novo padrão, mas 
ainda mantendo retrocompatibilidade com programas exis¬ 
tentes. Essa espécie de evolução é comum na indústria dos 
computadores, na medida em que nenhum fabricante iria 
querer lançar um sistema que nenhum de seus clientes 
pudesse utilizar sem passar por grandes adaptações. A ver¬ 
são do mintx, descrita neste livro, é baseada no padrão do 
POSIX (diferente da versão descrita na primeira edição, que 
era baseada na V7). 

Como o UNIX, o mintx foi escrito na linguagem de pro¬ 
gramação C e projetado para ser facilmente portado para 
vários computadores. A implementação inicial era para o 
IBM PC, pois esse computador é mais amplamente utiliza¬ 
do. Posteriormente, ele foi portado para computadores Atari, 
Amiga, Macintosh e SPARC. Para manter-se fiel à filosofia 


“quanto menor, melhor”, o mintx originalmente não exi¬ 
gia sequer um disco rígido, trazendo-o assim para alcance 
do orçamento de muitos alunos (por mais que pareça sur¬ 
preendente hoje, em meados da década de 80 quando o 
MINTX nascia, os discos rígidos ainda eram uma cara novi¬ 
dade). À medida que o mintx crescia em funcionalidade e 
tamanho, acabou chegando um momento em que um dis¬ 
co rígido era necessário, mas fiel à filosofia do mintx, uma 
partição de 30 megabytes é suficiente. Em contraste, al¬ 
guns sistemas comerciais UNIX agora recomendam, pelo 
menos, uma partição de disco de 200MB como o mínimo. 

Para o usuário médio que utiliza um IBM PC. rodar o 
MINTX é semelhante a rodar o UNIX. Muitos dos programas 
básicos, como cat. grep. Is. make, e o shell estão presentes 
e executam as mesmas funções que seus correspondentes 
no UNIX. Como o sistema operacional em si, todos esses 
programas utilitários foram reescritos completamente a 
partir do zero pelo autor e por seus alunos entre outras 
pessoas dedicadas. 

Ao longo deste livro, o MINIX será utilizado como um 
exemplo. Mas a maioria dos comentários sobre o MINTX, 
exceto aqueles sobre o código em si. também aplica-se ao 
UNIX. Muitos deles também aplicam-se a outros sistemas. 
Essa observação deve ser mantida em mente durante a lei¬ 
tura do texto. 

Como um parêntese, algumas palavras sobre o LINUX e 
seu relacionamento com o mintx podem ser de interesse 
para alguns leitores. Logo depois que o MINTX foi lançado, 
um grupo de discussão da USENET foi criado para discuti- 
lo. Em algumas semanas o grupo tinha 40.000 assinantes, 
grande parte dos quais queria adicionar um grande núme¬ 
ro de novos recursos ao mintx para torná-lo maior e me¬ 
lhor (bem, pelo menos maior). Todos os dias. várias cente¬ 
nas deles ofereciam sugestões, idéias e pequenos trechos de 
código. O autor do MINIX resistiu com êxito a esse assalto 
por vários anos para manter o MINIX suficientemente pe¬ 
queno e limpo para os alunos entenderem-no. Gradual¬ 
mente, começou a tornar-se evidente o que ele realmente 
significava. Nesse ponto, um estudante finlandês, Linus Tor- 
valds, decidiu escrever um clone do mintx projetado para 
ser um sistema de produção carregado de recursos, em vez 
de uma ferramenta educacional. Assim nascia o LINUX. 


1.3 CONCEITOS DE SISTEMA 
OPERACIONAL 

A interface entre o sistema operacional e os programas 
de usuário é definida pelo conjunto de “instruções estendi¬ 
das” que o sistema operacional proporciona. Essas instru¬ 
ções estendidas tradicionalmente foram conhecidas como 
chamadas de sistema {system calls), embora possam ser 
implementadas de várias maneiras hoje. Para realmente 
entender o que os sistemas operacionais fazem, devemos 
examinar essa interface bem de perto. As chamadas dispo- 
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níveis na interface variam de sistema operacional para sis¬ 
tema operacional (embora os conceitos subjacentes ten¬ 
dam a ser semelhantes). 

Assim, somos forçados a fazer uma escolha entre (1) 
generalidades vagas (“sistemas operacionais têm chama¬ 
das de sistema para ler arquivos") e (2) algum sistema 
específico (“o MINIX tem uma chamada de sistema read 
com três parâmetros: um para especificar o arquivo, um 
para dizer onde os dados devem ser colocados e um para 
indicar quantos bytes serão lidos"). 

Escolhemos a última abordagem. Ela é mais trabalho¬ 
sa, mas oferece uma visão melhor sobre o que os sistemas 
operacionais realmente fazem. Na Seção 1.4, veremos mais 
de perto as chamadas de sistema presentes tanto no UNIX 
como no MiNix. Para simplificar, iremos referir-nos só ao 
MINIX, mas as chamadas de sistema correspondentes do UNIX 
são baseadas no POSIX na maioria dos casos. Antes de exa¬ 
minarmos as chamadas de sistema reais, porém, vale a pena 
dar uma rápida olhada no minix, para obter uma visão 
geral do que é um sistema operacional como um todo. Essa 
visão geral aplica-se igualmente bem ao UNIX. 

As chamadas de sistema do minix dividem-se grosseira¬ 
mente em duas categorias amplas: aquelas que lidam com 
processos e aquelas que lidam com o sistema de arquivos. 
Examinaremos agora cada uma delas separadamente. 

1.3.1 Processos 

Um conceito-chave no minix e em todos sistemas ope¬ 
racionais é o processo. Um processo é basicamente um 
programa em execução. Associado com cada processo está 
seu espaço de endereçamento, uma lista de locais da 
memória a partir de um mínimo (normalmente 0) até um 
máximo, que o processo pode ler e gravar. 0 espaço de en¬ 
dereçamento contém o programa executável, os dados do 
programa e sua pilha. Também associado com cada pro¬ 
cesso está um conjunto de registradores, incluindo o con¬ 
tador de programa, o ponteiro da pilha e outros registrado¬ 
res de hardware e todas as demais informações necessárias 
para executar o programa. 

Voltaremos ao conceito de processo em muito mais de¬ 
talhe no Capítulo 2, mas, por enquanto, a maneira fácil de 
obter uma boa noção de um processo é pensar nos siste¬ 
mas de tempo compartilhado. Periodicamente, o sistema 


operacional decide parar de executar um processo e come¬ 
çar a executar outro, por exemplo, porque o primeiro teve 
mais que sua parte de tempo de CPU no segundo passado. 

Quando um processo é suspenso temporariamente como 
esse, mais tarde deve ser reiniciado exatamente no mesmo 
estado em que estava quando foi suspenso. Isso significa 
que todas as informações sobre o processo devem ser expli¬ 
citamente salvas em algum lugar durante a suspensão. Por 
exemplo, o processo pode ter vários arquivos abertos para 
leitura. Associado a cada um desses arquivos está um pon¬ 
teiro que informa a posição atual (i. e., o número do byte 
ou registro a ser lido em seguida). Quando um processo é 
suspenso temporariamente, todos esses ponteiros devem ser 
salvos para que uma chamada read executada depois que 
o processo é reiniciado leia os dados adequados. Em mui¬ 
tos sistemas operacionais, todas as informações sobre cada 
processo, que não o conteúdo do seu próprio espaço de en¬ 
dereçamento, são armazenadas em uma tabela do sistema 
operacional chamada tabela de processos, que é uma 
matriz (ou lista encadeada) de estruturas, uma para cada 
processo atualmente existente. 

Assim, um processo (suspenso) consiste em seu espaço 
de endereço, normalmente chamado imagem de núcleo 
(em homenagem às memórias de núcleo magnético utili¬ 
zadas antigamente), e sua entrada na tabela de processos, 
que contém seus registradores, entre outras coisas. 

As chamadas-chave do sistema de gerenciamento de 
processos são as que lidam com a criação e com o encerra¬ 
mento de processos. Considere um exemplo típico. Um pro¬ 
cesso chamado interpretador de comandos ou shell lê 
comandos de um terminal. 0 usuário digitou um coman¬ 
do que requisita a compilação de um programa. O shell 
agora deve criar um novo processo que executará o compi¬ 
lador. Quando esse processo termina a compilação, ele exe¬ 
cuta uma chamada de sistema para encerrar-se. 

Se um processo pode criar um ou mais processos (refe¬ 
ridos como processos-filho), os quais podem criar pro¬ 
cessos-filho, rapidamente chegamos à estrutura de árvore 
de processos da Figura 1-5. Processos relacionados que es¬ 
tão cooperando para executar uma tarefa freqüentemente 
precisam comunicar-se entre si e sincronizar suas ativida¬ 
des. Essa comunicação é chamada de comunicação in- 
terprocessos e será abordada detalhadamente no Capítu¬ 
lo 2. 



Figura 1-5 Uma árvore de processos. O processo A criou dois 
processos-filho, BeC.O processo B criou três processos-filho, D,EeF. 
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Outras chamadas de sistema para processos estão dis¬ 
poníveis para requisitar mais memória (ou liberar memó¬ 
ria não-utilizada), esperar um processo-filho terminar e 
substituir seu programa por um diferente. 

Ocasionalmente, há necessidade de transmitir as infor¬ 
mações para um processo em execução que não está para¬ 
do aguardando-as. Por exemplo, um processo que está co¬ 
municando-se com outro em um computador diferente faz 
isso enviando mensagens por uma rede. Para evitar a pos¬ 
sibilidade de que uma mensagem ou sua resposta seja per¬ 
dida, o remetente pode requisitar que o próprio sistema 
operacional notifique-o depois de um número especifica¬ 
do de segundos, de modo que ele possa retransmitir a men¬ 
sagem se nenhuma confirmação foi recebida ainda. De¬ 
pois de configurar esse temporizador, o programa pode con¬ 
tinuar fazendo outro trabalho. 

Quando o número especificado de segundos passou, o 
sistema operacional envia um sinal para o processo. 0 si¬ 
nal faz com que o processo suspenda temporariamente o 
que estava fazendo, salve seus registradores na pilha e co¬ 
mece a executar um procedimento especial de tratamento 
de sinal, por exemplo, para retransmitir uma mensagem 
presumivelmente perdida. Quando a manipulação do si¬ 
nal estiver concluída, o processo em execução é reiniciado 
no estado em que estava antes do sinal. Os sinais são o 
análogo de software das interrupções de hardware e podem 
ser gerados por uma variedade de causas além da expira¬ 
ção de temporizadores. Muitas exceções detectadas por har¬ 
dware, como executar uma instrução ilegal ou usar um 
endereço inválido, também são convertidas em sinais para 
o processo causador. 

A cada pessoa autorizada a utilizar o minix é designado 
com uma uid (de user identification — identificação de 
usuário) pelo administrador de sistema. Cada processo ini¬ 
ciado no minix tem a uid da pessoa que o iniciou. Um pro¬ 
cesso-filho tem a mesma uid que seu pai. Uma uid, deno¬ 
minada superusuário, tem poder especial e pode trans¬ 
gredir muitas das regras de proteção. Em instalações gran¬ 
des, só o administrador de sistema sabe a senha necessária 
para tornar-se superusuário, mas muitos dos usuários co¬ 
muns (especialmente estudantes) despendem esforço con¬ 
siderável tentando localizar defeitos no sistema que os per¬ 
mitam tornar-se superusuário sem a senha. 

1.3.2 Arquivos 

A outra categoria ampla de chamadas de sistema está 
relacionada com o sistema de arquivos. Como observado 
anteriormente, uma função importante do sistema opera¬ 
cional é esconder as peculiaridades dos discos e outros dis¬ 
positivos de E/S e apresentar ao programador um amigá¬ 
vel e limpo modelo abstrato de arquivos independentes de 
dispositivo. As chamadas de sistema obviamente são ne¬ 
cessárias para criar, para remover, para ler e para escrever 
arquivos. Antes de um arquivo poder ser lido, ele deve ser 
aberto e depois de lido deve ser fechado, assim chamadas 
são fornecidas para fazer tais coisas. 


Para fornecer um lugar para manter os arquivos, o MI- 
NTX tem o conceito de diretório como uma maneira de 
agrupar os arquivos. Um aluno, por exemplo, talvez tenha 
um diretório para cada curso que ele está fazendo (para os 
programas necessários para esse curso), outro diretório para 
seu correio eletrônico e ainda um terceiro diretório para 
sua home page na World Wide Web. As chamadas de siste¬ 
ma, então, são necessárias para criar e para remover dire¬ 
tórios. Chamadas também são fornecidas para inserir um 
arquivo em um diretório existente, bem como para remo¬ 
ver um arquivo de um diretório. As entradas de diretório 
podem ser arquivos ou outros diretórios. Esse modelo tam¬ 
bém origina uma hierarquia — o sistema de arquivos —, 
como mostrado na Figura 1-6. 

Tanto as hierarquias de processos quanto as de arqui¬ 
vos são organizadas como árvores, mas as semelhanças 
param por aí. As hierarquias de processos normalmente 
não são muito profundas (mais de três níveis é raro), ao 
passo que as hierarquias de arquivo têm comumente qua¬ 
tro, cinco e até mais níveis de profundidade. Além disso, as 
hierarquias de processos normalmente têm vida curta, em 
geral, alguns minutos no máximo, enquanto as hierarquias 
de diretórios podem existir durante anos. A posse e a prote¬ 
ção também diferem para processos e para arquivos. Nor¬ 
malmente, só um processo-pai pode controlar ou mesmo 
acessar um processo-filho, mas quase sempre existem me¬ 
canismos para permitir que arquivos e diretórios sejam li¬ 
dos por um grupo mais amplo que apenas o proprietário. 

Cada arquivo dentro da hierarquia de diretórios pode 
ser especificado dando-se seu nome de caminho a partir 
do topo da hierarquia de diretórios, o diretório-raiz. Es¬ 
ses nomes de caminho absolutos consistem na lista de di¬ 
retórios que deve ser percorrida a partir do diretório-raiz 
para alcançar o arquivo, com barras separando os compo¬ 
nentes. Na Figura 1-6, o caminho para o arquivo CS 101 é/ 
Faculdade/Prof.Brown/Cursos/CSIOl. A primeira barra 
indica que o caminho é absoluto, isto é, inicia-se no dire¬ 
tório-raiz. 

A cada instante, cada processo tem um diretório de 
trabalho atual, onde os nomes de caminho que não co¬ 
meçam com uma barra são procurados. Como um exem¬ 
plo, na Figura 1-6, se /Faculdade/Prof.Brown fosse o di¬ 
retório de trabalho, então, o uso do nome de caminho Cur- 
sos/CSWl resultaria no mesmo arquivo que o nome de 
caminho absoluto dado acima. Os processos podem mu¬ 
dar seu diretório de trabalho emitindo uma chamada de 
sistema que especifica o novo diretório de trabalho. 

Os arquivos e os diretórios no minix são protegidos de¬ 
signando um código binário de proteção de 9 bits a cada 
um. O código de proteção consiste em três campos de 3 
bits, um para o proprietário, um para outros membros do 
grupo do proprietário (os usuários são divididos em gru¬ 
pos pelo administrador do sistema) e um terceiro para to¬ 
das as demais pessoas. Cada campo tem um bit para acesso 
de leitura ( reaü ’), um bit para acesso de gravação ( write ) e 
um bit para acesso de execução. Esses 3 bits são conheci¬ 
dos como bits rwx. Por exemplo, o código de proteção 
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Diretório-raiz 



Figura 1-6 Um sistema de arquivos para um departamento de uma universidade. 


rwxr-x-x significa que o proprietário pode ler, gravar ou 
executar o arquivo, outros membros de grupo podem ler 
ou executar (mas não gravar) o arquivo e todas as demais 
pessoas podem executar (mas não ler ou gravar) o arqui¬ 
vo. Para um diretório, x indica permissão de pesquisa. Um 
traço significa que a permissão correspondente está ausen¬ 
te. 

Antes de um arquivo poder ser lido ou gravado, ele deve 
ser aberto, momento em que as permissões são verificadas. 
Se o acesso for permitido, o sistema retorna um número 
inteiro pequeno chamado descritor de arquivo para usar 
em operações subseqüentes. Se o acesso for proibido, um 
código de erro é retornado. 

Outro conceito importante no MINIX é o sistema de ar¬ 
quivos montados. Quase todos os computadores pessoais 
têm uma ou mais unidades de disquete onde os disquetes 
podem ser inseridos e removidos. Para fornecer uma ma¬ 
neira limpa de lidar com essas mídias removíveis (e tam¬ 
bém CD-ROMs, que são também removíveis), o MINIX per¬ 
mite que o sistema de arquivos em um disquete seja unido 
à árvore principal. Considere a situação da Figura 1-7(a). 
Antes da cjiamada mount, o disco de RAM (disco simulado 
na memória principal) contém o sistema de arquivos- 
raiz ou primário, e a unidade 0 contém um disquete que, 
por sua vez, contém outro sistema de arquivos. 


Entretanto, o sistema de arquivos na unidade 0 não pode 
ser utilizado porque não há como especificar nomes de 
caminho nele. O minix não permite que os nomes de cami¬ 
nho tenham como prefixo um nome de unidade ou um 
número; isso seria precisamente o tipo de dependência de 
dispositivo que os sistemas operacionais deveriam elimi¬ 
nar. Em vez disso, a chamada de sistema MOUNT permite 
que o sistema de arquivos na unidade 0 seja anexado ao 
sistema de arquivos raiz onde quer que o programa queira 
que ele esteja. Na Figura 1-7(b), o sistema de arquivos na 
unidade 0 foi montado no diretório b, permitindo, assim, 
acesso aos arquivos /b/x e/b/y. Se o diretório b contivesse 
qualquer arquivo, esse não seria acessível enquanto a uni¬ 
dade 0 estivesse montada, uma vez que/i b iria referir-se ao 
diretório-raiz da unidade 0. (Ser incapaz de acessar esses 
arquivos não é tão sério quanto a princípio pode parecer: 
os sistemas de arquivos quase sempre são montados em 
diretórios vazios.) 

Outro conceito importante no MINIX é o de arquivo 
especial, fornecido para fazer dispositivos de E/S parece¬ 
rem arquivos. Assim, eles podem ser lidos e gravados usan¬ 
do as mesmas chamadas de sistema utilizadas para ler e 
para gravar arquivos. Há dois tipos de arquivos especiais: 
arquivos especiais de bloco e arquivos especiais de 
caractere. Os arquivos especiais de bloco são utilizados 
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Figura 1-7 (a) Antes da montagem, os arquivos na 

eles são parte da hierarquia de arquivos. 


para modelar dispositivos que consistem em uma coleção 
de blocos aleatoriamente endereçáveis, como disços. Abrin¬ 
do um arquivo especial de bloco e lendo, digamos, o bloco 
4, um programa pode acessar diretamente o quarto bloco 
no dispositivo, sem considerar a estrutura do sistema de 
arquivos contida nele. De maneira semelhante, arquivos 
especiais de caractere são utilizados para modelar impres¬ 
soras, modems e outros dispositivos que aceitam ou dão 
como saída um fluxo de caracteres. 

0 último recurso que discutiremos nesta visão geral está 
relacionado tanto com processos como com arquivos: pi- 
pes. Um pipe é um tipo de pseudo-arquivo que pode ser 
utilizado para conectar dois processos (Figura 1-8 adian¬ 
te) . Quando o processo A quer enviar dados para o processo 
B, ele grava no pipe como se fosse um arquivo de saída. O 
processo B pode ler os dados lendo a partir do pipe como se 
fossem um arquivo de entrada. Assim, a comunicação en¬ 
tre processos no minix parece-se muito com a leitura e com 
a gravação comuns de arquivos. Além de tudo, a única ma¬ 
neira como um processo pode descobrir que o arquivo de 
saída que ele está gravando não é realmente um arquivo, 
mas um pipe, é fazendo uma chamada especial de sistema. 

1.3.3 O Shell 

0 sistema operacional minix é o código que executa as 
chamadas de sistema. Os editores, compiladores, assem- 
blers, montadores e interpretadores de comando definiti¬ 
vamente não são parte do sistema operacional, ainda que 
sejam importantes e úteis. Sob o risco de confundir um 
pouco as coisas, veremos nesta seção resumidamente, o 
interpretador de comandos do MINIX, chamado shell, que, 
embora não seja parte do sistema operacional, faz uso pe¬ 
sado de muitos recursos do sistema operacional e, assim, 
serve como um bom exemplo de como as chamadas de sis¬ 
tema podem ser utilizadas. Ele também é a interface pri¬ 
mária entre o usuário à frente do terminal e o sistema ope¬ 
racional. 

Quando qualquer usuário efetua logon, um shell é ini- 
cializado. 0 shell tem o terminal como entrada-padrão e 



(b) 


unidade 0 não são acessíveis, (b) Depois da montagem. 


saída-padrão. Ele inicia apresentando o prompt, um ca¬ 
ractere como o sinal de cifrão, que informa ao usuário que 
o shell está esperando receber um comando. Se o usuário 
agora digitar 

date 

por exemplo, o shell cria um processo-filho e executa o pro¬ 
grama date como o filho. Enquanto o processo-filho está 
executando, o shell espera que ele termine. Quando o filho 
termina, o shell exibe o prompt novamente e tenta ler a 
próxima linha de entrada. 

O usuário pode especificar que a saída-padrão seja re¬ 
direcionada para um arquivo, por exemplo, 

date >file 

De maneira semelhante, a entrada-padrão pode ser redire¬ 
cionada, como em 

sort <file1 >file2 

que invoca o programasor/ que pega a entrada àefilei e a 
envia ao arquivo de saída file2. 

A saída de um programa pode ser utilizada como a en¬ 
trada para outro programa, conectando-os com um pipe. 
Assim, 

cat filei file2 file3 | sort >/dev/lp 

invoca o programa cat para concatenar três arquivos e en¬ 
viar a saída para sort organizar todas as linhas em ordem 
alfabética. A saída de sort é redirecionada para o arquivo / 
dev/lp, que é um típico nome de arquivo especial de carac¬ 
tere para impressora. (Por convenção, todos os arquivos 
especiais são mantidos no diretório /dev.) 

Se um usuário colocar o caractere & depois de um co¬ 
mando, o shell não o espera completar. Em vez disso, ele 
simplesmente apresenta o prompt imediatamente. Conse¬ 
quentemente, 

cat filei file2 file3 | sort >/dev/lp & 

inicializa sort como um job em segundo plano, permitin¬ 
do que o usuário continue a trabalhar normalmente en- 
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Figura 1-8 Dois processos conectados por um pipe. 


quanto sort está em execução. 0 shell tem diversos outros 
recursos interessantes que não temos espaço para discutir 
aqui. Consulte qualquer uma das referências sugeridas so¬ 
bre o UNIX para obter mais informações sobre o shell. 

1.4 CHAMADAS DE SISTEMA 

Munidos de nosso conhecimento geral sobre como o 
MlNix lida com processos e arquivos, podemos começar, 
agora, a examinar a interface entre o sistema operacional 
e seus programas aplicativos, isto é, o conjunto de chama¬ 
das de sistema. Embora essa discussão refira-se especifica¬ 
mente ao posix (International Standard 9945-1), e por¬ 
tanto também ao MINIX, a maioria dos outros sistemas ope¬ 
racionais modernos têm chamadas de sistema que execu¬ 
tam as mesmas funções, ainda que alguns detalhes pos¬ 
sam ser diferentes. Como a verdadeira mecânica de uma 
chamada de sistema depende muito da máquina e frequen¬ 
temente deve ser expressa em código assembler, uma bi¬ 
blioteca de procedimentos é fornecida para tornar possível 
fazer chamadas de sistema a partir de programas em C. 

Para tomar o mecanismo de chamadas de sistema mais 
claro, vamos examinar brevemente um READ. Ele tem três 
parâmetros: o primeiro especifica o arquivo, o segundo, o 
buffer e o terceiro especifica o número de bytes a ler. Uma 
chamada READ de um programa em C pode se parecer com 
isto: 

count = read(file, buffer, nbytes); 

A chamada de sistema (e o procedimento de biblioteca) 
retorna o número de bytes realmente lido em count. Esse 
valor é normalmente o mesmo que nbytes, mas pode ser 
menor, se, por exemplo, o fim do arquivo for encontrado 
durante a leitura. 

Se a chamada de sistema não puder ser executada, seja 
devido a um parâmetro inválido, seja devido a um erro de 
disco, count é definido como -1 e o número do erro é colo¬ 
cado em uma variável global, ermo. Os programas sem¬ 
pre devem verificar os resultados de uma chamada de sis¬ 
tema para ver se um erro ocorreu. 

0 MlNix tem um total de 53 chamadas de sistema que 
estão listadas na Figura 1-9, agrupadas por conveniência 
em seis categorias. Nas seções a seguir, examinaremos re¬ 
sumidamente cada chamada para ver o que elas fazem. De 
maneira geral, os serviços oferecidos por tais chamadas 
determinam a maior parte do que o sistema operacional 
tem de fazer, uma vez que o gerenciamento de recursos em 


computadores pessoais é mínimo (pelo menos em compa¬ 
ração com máquinas de maior porte, com muitos usuári¬ 
os). 

Como um parêntese, vale indicar que o significado de 
chamada de sistema está aberto a interpretações. 0 padrão 
POSIX especifica um número de procedimentos que um sis¬ 
tema compatível deve fornecer, mas não se são chamadas 
de sistema, chamadas de bibliotecas, ou qualquer outra 
coisa. Em alguns casos, os procedimentos do posix são su¬ 
portados como rotinas de biblioteca em minix. Em outros, 
vários procedimentos necessários são apenas variações 
menores um do outro, e uma chamada de sistema trata 
todos eles. 

1.4.1 Chamadas de Sistema para 
Gerenciamento de Processos 

0 primeiro grupo de chamadas trata do gerenciamento 
de processos. FORK é um bom lugar para começar a discus¬ 
são. fork é o único meio de criar um novo processo. Ele 
cria uma duplicata exata do processo original, incluindo 
todos os descritores de arquivos, registradores — tudo. De¬ 
pois de fork, o processo original e a cópia (pai e filho) 
seguem caminhos diferentes. Todas as variáveis têm valo¬ 
res idênticos no momento do fork, mas como os dados do 
pai são copiados para criar o filho, posteriores mudanças 
em um deles não afetam o outro. (0 texto, que é imutável, 
é compartilhado entre pai e filho.) A chamada fork retor¬ 
na um valor, que é zero no filho e igual ao identificador de 
processo (ou pid, de process identifier) do filho no pai. 
Usando o pid retornado, os dois processos podem ver qual é 
o processo-pai e qual é o processo-filho. 

Na maioria dos casos, depois de um FORK, o filho preci¬ 
sará executar um código diferente do pai. Considere o caso 
do shell. Ele lê um comando do terminal, cria um proces¬ 
so-filho, espera o filho executar o comando e, então, lê o 
próximo comando quando o filho termina. Para esperar o 
filho terminar, o pai executa uma chamada de sistema 
waitpid, que espera até o filho terminar (qualquer filho, se 
existir mais de um), waitpid pode esperar um filho especí¬ 
fico ou qualquer filho, definindo o primeiro parâmetro 
como -1. Quando waitpid completa-se, o endereço aponta¬ 
do pelo segundo parâmetro contém o status de saída do 
filho (término normal ou anormal e valor de saída). Vári¬ 
as opções também são oferecidas. A chamada waitpid subs¬ 
titui a chamada WAIT anterior, que agora é obsoleta, mas 
continua sendo fornecida por razões de retrocompatibili- 
dade. 
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Gerenciamento de processos 

pid = fork() 

pid = waitpid(pid, &statloc, opts) 

s = wait(&status) 

s = execve(name, argv, envp) 

exit(status) 

size = brk(addr) 

pid = getpid() 

pid = getpgrp() 

pid = setsid() 

1 = ptrace(req, pid, addr, data) 

Cria um processo-filho idêntico ao pai 

Espera um filho terminar 

Versão antiga de waitpid 

Substitui a imagem de núcleo de um processo 

Termina a execução do processo e retorna o status 

Define o tamanho do segmento de dados 

Retorna o id do processo que fez a chamada 

Retorna o id do grupo do processo que fez a chamada 

Cria uma nova sessão e retorna o id do seu grupo de processo 

Utilizado para depuração 

Sinais 

s = sigaction(sig, &act, &oldact) 

s = sigreturn(&context) 

s = sigprocmask(how, &set, &old) 

s = sigpending(set) 

s = sigsuspend(sigmask) 

s = kill(pid, sig) 

residual = alarm(seconds) 

s = pause() 

Define a ação a executar em sinais 

Retorna de um sinal 

Examina ou muda a máscara do sinal 

Obtém o conjunto de sinais bloqueados 

Substitui a máscara de sinal e suspende o processo 

Envia um sinal para um processo 

Define um temporizador 

Suspende o processo que fez a chamada até o próximo sinal 

Gerenciamento de arquivos 

fd = creat(name, mode) 
fd = mknod(name, mode, addr) 
fd = open(file, how,...) 
s = dose(fd) 

n = read(fd, buffer, nbytes) 
n = write(fd, buffer, nbytes) 
pos = lseek(fd, offset, whence) 
s = stat(name, &but) 
s = fstat(fd, &buf) 
fd = dup(fd) 
s = pipe(&fd[0]) 
s = ioctl(fd, request, argp) 
s = access(name, amode) 
s = rename(old, new) 
s = fcntl(fd, cmd,...) 

Modo obsoleto de criar um novo arquivo 

Cria um nó-i especial, normal, ou de diretório 

Abre um arquivo para ler, gravar ou ambos 

Fecha um arquivo aberto 

tê dados de um arquivo em um buffer 

Grava dados de um buffer em um arquivo 

Move o ponteiro do arquivo 

Obtém informações de status de um arquivo 

Obtém informações de status de um arquivo 

Atribui um novo descritor de arquivo a um arquivo aberto 

Cria um pipe 

Executa operações especiais em um arquivo 

Verifica a acessibilidade do arquivo 

Atribui um novo nome a um arquivo 

Bloqueio de arquivo e outras operações 

Gerenciamento de diretório & de 
sistema de arquivos 

s = mkdir(name, mode) 
s = rmdir(name) 
s = link(namel, name2) 
s = unlink(name) 
s = mount(special, name, flag) 
s = umount(special) 
s - sync() 
s = chdir(dirname) 
s = chroot(dirname) 

Cria um novo diretório 

Remove um diretório vazio 

Cria uma nova entrada, name2, apontando para namel 

Remove uma entrada de diretório 

Monta um sistema de arquivos 

Desmonta um sistema de arquivos 

Envia todos os blocos em cache para o disco 

Muda o diretório de trabalho 

Muda o diretório-raiz 

Proteção 

s = chmod(name, mode) 
uid = getuid() 
gid = getgidj) 
s = setuid(uid) 
s = setgid(gid) 

s = chown(name, owner, group) 
oldmask = umask(complmode) 

Muda os bits de proteção de um arquivo 

Obtém o uid do processo que fez a chamada 

Obtém o gid do processo que fez a chamada 

Define o uid do processo que fez a chamada 

Define o gid do processo que fez a chamada 

Muda um proprietário do arquivo e grupo 

Muda a máscara de modo 

Gerenciamento de tempo 

seconds = time(&seconds) 
s = stime(tp) 
s = utime(file, timep) 
s = times(buffer) 

Obtém o tempo passado desde 1 B de Jan., 1970 

Define o tempo passado desde 1 Q de Jan., 1970 

Define o momento de “último acesso” de um arquivo 

Obtém os tempos do usuário e do sistema utilizados até agora 


Figura 1-9 As chamadas de sistema do MINIX. 0 código de retorno é -1 se um erro ocorreu;^ é um descritor de arquivo e n é 
contagem de byte. Os outros códigos de retorno são o que o nome sugere. 


Agora considere como FORK é utilizado pelo shell. Quan¬ 
do um comando é digitado, o shell cria um novo processo. 
Esse processo-filho deve executar o comando do usuário. 
Ele faz isso usando a chamada de sistema EXEC, que faz 
com que toda sua imagem de núcleo seja substituída pelo 
arquivo nomeado em seu primeiro parâmetro. Um shell 
extremamente simplificado ilustrando o uso de FORK, wai- 
TPID e EXEC e' mostrado na Figura 1-10. 


No caso mais genérico, exec tem três parâmetros: o 
nome do arquivo a ser executado, um ponteiro para a ma¬ 
triz de argumentos e um ponteiro para a matriz de ambi¬ 
ente. Esses serão descritos resumidamente. Várias rotinas 
de biblioteca, incluindo execl, execv, execle e execve são 
fornecidas para permitir que os parâmetros sejam omiti¬ 
dos ou especificados de diferentes maneiras. Ao longo de 
todo este livro, usaremos o nome EXEC para representar a 
chamada de sistema invocada por todas elas. 
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while (TRUE) { /* repete indefinidamente 7 

read_command(command, parameters); /* lê a entrada do terminal 7 


if (fork()!= 0) { /* cria o processo-filho 7 

/* Código pai. 7 

waitpid(-1 , &status, 0); /* espera o filho encerrar 7 

} else { 

/* Código filho. 7 

execvefcommand, parameters, 0); /* executa o comando 7 

} 

} 


Figura 1-10 Um sbell simplificado. Neste livro, supõe-se que TRUE seja definido como 1. 


Considere o caso de um comando como 

cp filei file2 

utilizado para copiar filei para file2. Depois que o shell é 
bifurcado, o processo-filho localiza e executa o arquivo cp 
e passa para ele os nomes dos arquivos de origem e de des¬ 
tino. 

0 programa principal de cp (e o programa principal da 
maioria dos outros programas) contém a declaração 

main(argc, argv, envp) 

onde o argc é uma contagem do número de itens na linha 
de comando, incluindo o nome do programa. Para o exem¬ 
plo acima, argcé 3. 

0 segundo parâmetro, argv, é um ponteiro para uma 
matriz. O elemento i dessa matriz é um ponteiro para a i- 
ésima string" na linha de comando. Em nosso exemplo, o 
argv [0] apontaria para a string “cp”. De maneira seme¬ 
lhante, argv [1] apontaria para a string de 5 caracteres 
“filei” e o argv [2] apontaria para a string de 5 caracteres 
“file2”. 

0 terceiro parâmetro de main , envp, é um ponteiro 
para o ambiente, uma matriz d estrings que contém desig¬ 
nações na forma nome = valor utilizados para passar in¬ 
formações como o tipo do terminal e o nome do diretório 
inicial para um programa. Na Figura 1-10, nenhum am¬ 
biente é passado para o filho, então para o terceiro parâ¬ 
metro de execve é zero. 

Se EXEC parece complicado, não se desespere; ela é a 
chamada de sistema mais complexa. Todas as demais são 
muito mais simples. Como um exemplo simples, considere 
EXIT, que os processos devem usar quando concluem sua 
execução. Ela tem um parâmetro, o status de saída (0 a 
255), que é retornado para o pai na variável status da cha¬ 
mada de sistema wait ou waitpid. O byte de ordem inferior 
de status contém o status do término, com 0 sendo término 
normal e os outros valores sendo várias condições de erro. 
0 byte de ordem superior contém o status de saída do filho 


"N. de R. String: Cadeia. Uma estrutura de dados composta por uma 
série de caracteres, geralmente contendo um texto legível e inteligível 
pelas pessoas. ( Dicionário de Informática. Microsoft Press. Rio de 
Janeiro, Editora Campus, 1998). 


(0 a 255). Por exemplo, se um processo-pai executa a ins¬ 
trução 

n = waitpid(-1, &status, options); 

ele será suspenso até que algum processo-filho termine. Se 
o filho sai com, digamos, 4 como parâmetro de exit, o pai 
será despertado com n definido como o pid do filho e o 
status definido como 0x0400 (a convenção em C de utili¬ 
zar o prefixo 0x para constantes hexadecimais será utiliza¬ 
da em todo o livro). 

Os processos no MiNix têm sua memória dividida em 
três segmentos: o segmento de texto (i. e., o código do 
programa), o segmento de dados (i. e., as variáveis) e o 
segmento de pilha. 0 segmento de dados cresce para cima, 
e a pilha, para baixo, como mostrado na Figura 1-11. En¬ 
tre eles, há um intervalo de endereços não-utilizados. A pi¬ 
lha cresce automaticamente, conforme o necessário, mas 
a expansão do segmento de dados é feita explicitamente 
usando a chamada de sistema BRK. Ela tem um parâme¬ 
tro, que fornece o endereço onde o segmento de dados deve 
terminar. Esse endereço pode ser maior que o valor atual 
(o segmento de dados está aumentando) ou menor que o 
valor atual (o segmento de dados está diminuindo). 0 pa¬ 
râmetro deve, naturalmente, ser menor que o ponteiro da 
pilha; caso contrário, os segmentos de dados e da pilha iriam 
sobrepor-se, o que é proibido. 

Como uma conveniência para o programador, é forne¬ 
cida uma rotina de biblioteca sbrk que também muda o 
tamanho do segmento de dados, só que seu parâmetro é o 
número de bytes a adicionar ao segmento de dados (parâ¬ 
metros negativos reduzem o segmento de dados). Ela fun¬ 
ciona acompanhando o tamanho atual do segmento de 
dados, que é o valor retornado por BRK, calculando o novo 
tamanho e fazendo uma chamada pedindo esse número 
de bytes. BRK e SBRK foram considerados demasiadamente 
dependentes de implementação e não são parte do POSIX. 

A próxima chamada de sistema de processo, GETPID, é 
também a mais simples. Ela apenas retorna o pid do pro¬ 
cesso que fez a chamada. Lembre-se de que em FORK, so¬ 
mente o pai recebeu o pid do filho. Se o filho quiser saber o 
próprio pid, deve usar GETPID. A chamada GETPGRP retoma 
o pid do grupo do processo que fez a chamada. SETSID cria 
uma nova sessão e define o pid do grupo como o do proces- 
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Endereço (hexa) 



Figura 1-11 Os processos têm três segmentos: texto, dados e pilha. 
Neste exemplo, os três estão em um espaço de endereço, mas o espaço 
separado para instruções e para dados também é suportado. 


so que fez a chamada. As sessões estão relacionadas a um 
recurso opcional do POSix chamado controle de job, que 
não é suportado pelo mintx e com o qual não nos ocupare¬ 
mos mais neste livro. 

A última chamada de sistema de gerenciamento de pro¬ 
cesso, PTRACE, é utilizada para depurar programas contro¬ 
lando o programa que está sendo depurado. Ela permite 
que o depurador leia e grave a memória do processo con¬ 
trolado e a gerencie de outras maneiras. 

1.4.2 Chamadas de Sistema para 
Sinalização 

Embora a maioria das formas de comunicação de in- 
terprocessos seja planejada, há situações nas quais uma 
comunicação inesperada é necessária. Por exemplo, se um 
usuário acidentalmente instrui um editor de texto a impri¬ 
mir o conteúdo inteiro de um arquivo muito longo e, en¬ 
tão, percebe o erro, é preciso haver alguma maneira de in¬ 
terromper o editor. No MINIX, o usuário pode utilizar a te¬ 
cla DEL, que envia um sinal para o editor. 0 editor recebe o 
sinal e cancela a impressão. Os sinais também podem ser 
utilizados para informar certas exceções detectadas pelo 
hardware, como instrução ilegal ou estouro de ponto flu¬ 
tuante. Os limites de tempo ( timeouts) também são im¬ 
plementados como sinais. 

Quando um sinal é enviado para um processo que não 
anunciou sua receptividade para esse sinal, o processo sim¬ 
plesmente é eliminado sem maior alarde. Para evitar esse 
destino, um processo pode usar a chamada de sistema SI- 
GACTION para anunciar que está preparado para aceitar al¬ 
gum tipo de sinal e fornecer o endereço do procedimento 
de manipulação do mesmo e um lugar para armazenar o 
endereço atual. Depois de uma chamada SIGACTION, se um 
sinal de tipo relevante (p. ex., a tecla DEL) é gerado, o esta¬ 
do do processo é colocado em sua própria pilha e, então, o 
manipulador de sinal é chamado. Ele pode executar por 
quanto tempo quiser e executar qualquer chamada de sis¬ 
tema que necessitar. Na prática, porém, os manipuladores 


de sinal, em geral, são relativamente curtos. Quando o pro¬ 
cedimento de manipulação de sinal está completo, ele cha¬ 
ma SIGRETLRN para continuar a partir de onde ele saiu 
antes do sinal. A chamada SIGACTION substitui a antiga 
chamada SIGNAL, que agora, por razões de retrocompatibi- 
lidade é fornecida como um procedimento de biblioteca. 

Os sinais podem ser bloqueados no MINIX. Um sinal blo¬ 
queado é mantido pendente até que seja desbloqueado. Ele 
não é enviado, mas também não é perdido. A chamada SI- 
GPROCMASK permite a um processo definir o conjunto de 
sinais bloqueados apresentando ao kernel um mapa de bits. 
Também é possível para um processo pedir o conjunto de 
sinais atualmente pendentes, mas que não puderam ser 
enviados devido ao seu estado bloqueado. A chamada si- 
GPENDING retorna esse conjunto como um mapa de bits. 
Finalmente, a chamada SIGSUSPEND permite que um pro¬ 
cesso defina atomicamente o mapa de bits dos sinais blo¬ 
queados e suspenda a si próprio. 

Em vez de oferecer uma função para capturar um si¬ 
nal, o programa também pode especificar a constante 
SIG_IGN para ignorar todos os sinais subseqüentes do tipo 
especificado, ou SIG_DFL para restaurar a ação-padrão do 
sinal quando este ocorrer. A ação-padrão é eliminar qual¬ 
quer processo ou ignorar o sinal, dependendo do sinal. 
Como um exemplo de como SIG_1GN é utilizado, conside¬ 
re o que acontece quando o shell cria um processo em se¬ 
gundo plano como resultado de 

command & 

seria indesejável que o sinal DEL do teclado afetasse o pro¬ 
cesso em segundo plano, então, depois de FORK mas antes 
de exec, o shell faz 

sigaction(SIGINT, SIGJGN, NULL); 
e 

sigaction(SIGQUIT, SIGJGN, NULL); 

para desabilitar os sinais DEL e QUIT. (O sinal de encerra¬ 
mento — quit — é gerado por CTRLA; que é o mesmo 
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que DEL, exceto que se não é capturado nem ignorado, ele 
faz um dump * do processo eliminado.) Para processos em 
primeiro plano (sem &), esses sinais não são ignorados. 

Pressionar a tecla DEL não é a única maneira de enviar 
um sinal. A chamada de sistema KII.L permite que um pro¬ 
cesso sinalize outro processo (desde que eles tenham o 
mesmo uid — processos não-relacionados não podem si¬ 
nalizar um para o outro). Voltando ao exemplo de proces¬ 
sos em segundo plano utilizado acima, suponha que um 
processo em segundo plano seja iniciado, mas mais tarde 
decida-se que o processo deve ser terminado. SIGIXT e SIG- 
QLIT foram desativados, então algo mais é necessário. A 
solução é usar o programa M/, que usa a chamada de sis¬ 
tema Klü. para enviar um sinal para qualquer processo. 
Enviando o sinal 9 (sigkii.l), para um processo em segun¬ 
do plano, esse processo pode ser eliminado. SIGKILL não pode 
ser capturado nem ignorado. 

Para muitos aplicativos de tempo real, um processo pre¬ 
cisa ser interrompido após um intervalo específico de tem¬ 
po para fazer algo, como retransmitir um pacote perdido 
em uma linha de comunicação pouco confiável. Para li¬ 
dar com essa situação, a chamada de sistema aiarm foi 
fornecida. 0 parâmetro especifica um intervalo, em segun¬ 
dos, depois de que um sinal SIGAI.RM é enviado para o pro¬ 
cesso. Um processo só pode ter um alarme por vez. Se uma 
chamada alarm é feita com um parâmetro de 10 segundos 
e, então, 3 segundos mais tarde outra chamada alarm é 
feita com um parâmetro de 20 segundos, só um sinal será 
gerado 20 segundos depois da segunda chamada. O pri¬ 
meiro sinal é cancelado pela segunda chamada alarm. Se 
o parâmetro ALARM for zero, qualquer sinal de alarme é 
cancelado. Se um sinal de alarme não for capturado a ação- 
padrão é tomada, e o processo sinalizado é eliminado. 

Às vezes, ocorre que um processo não tem nada a fazer 
até que um sinal chegue. Por exemplo, considere um pro¬ 
grama CAI ( Computer-Aided-Instruction — ensino auxi¬ 
liado por computador) que está testando velocidade de lei¬ 
tura e de entendimento. Ele exibe algum texto na tela e, 
então, chama alarm para sinalizá-lo depois de 30 segun¬ 
dos. Enquanto o aluno estiver lendo o texto o programa 
não tem nada a fazer. Ele poderia entrar em um laço sem 
fazer nada, mas isso desperdiçaria tempo da CPU que ou¬ 
tro processo ou usuário talvez precise. Uma idéia melhor é 
usar PAUSK, que instrui o MINIX a suspender o processo até 
o próximo sinal. 

1.4.3 Chamadas de Sistema para 
Gerenciamento de Arquivos 

Muitas chamadas de sistema estão relacionadas com o 
sistema de arquivos. Nesta seção examinaremos as cha¬ 
madas que funcionam em arquivos individuais; na próxi¬ 
ma, examinaremos as que envolvem diretórios ou o siste- 


"N. de R. Dump : Despejo binário. Parte da memória despejada em outro 
meio de armazenamento ou impressa em forma binária. 


ma de arquivos como um todo. Para criar um novo arqui¬ 
vo, a chamada CREATé utilizada (o motivo pêlo qual a cha¬ 
mada é CREAT e não CREATE foi esquecido nas névoas do 
tempo). Seus parâmetros fornecem o nome do arquivo e o 
modo de proteção. Assim 

fd = creat (“abc”, 0751); 

cria um arquivo chamado abc com modo 0751 octal (em 
C, um zero na frente significa que uma constante está em 
octal). Os 9 bits de ordem inferior de 0751 especificam os 
bits rwx para o proprietário (7 significa permissão para ler, 
gravar e para executar), seu grupo (5 significa permissão 
para ler e para executar) e outros (1 significa permissão só 
para executar). 

CREAT não só cria um novo arquivo, mas, também, o 
abre para escrita, independente do modo do arquivo. O des¬ 
critor de arquivo retornado, fd. pode ser utilizado para gra¬ 
var o arquivo. Se um CREAT é executado em um arquivo 
existente, esse arquivo é truncado para comprimento 0, 
desde que, naturalmente, todas as permissões estejam cor¬ 
retas. A chamada creat é obsoleta, já que open agora pode 
criar novos arquivos, mas ela foi incluída por razões de 
retrocompatibilidade. 

Arquivos especiais são criados utilizando MKXOD em vez 
de creat. Uma típica chamada é 

fd = mknod (“/dev/ttyc2”, 020744, 0x0402); 

que cria um arquivo chamado /dev/tty<c2 (o nome usual 
para o console 2) e lhe atribui o modo 020744 octal (um 
arquivo especial de caractere com bits de proteção rwxr—r- 
-). O terceiro parâmetro contém o dispositivo principal (4) 
no byte de ordem superior e o dispositivo secundário (2) 
no byte de ordem inferior. O dispositivo principal poderia 
ser qualquer coisa, mas um arquivo chamado / dev/ttyc2 
deve ser o dispositivo secundário 2. As chamadas para MK¬ 
NOD falham a menos que a chamada tenha sido feita pelo 
superusuário. 

Para ler ou para gravar um arquivo existente, o arquivo 
deve primeiro ser aberto usando OPEN. Essa chamada espe¬ 
cifica o nome do arquivo a ser aberto, seja um nome de 
caminho absoluto ou relativo ao diretório de trabalho, e 
para um código de 0_RDONIY, OJXKOAWou 0_RDWR, 
que significam aberto para leitura, para gravação ou para 
ambos. O descritor de arquivo retornado, então, pode ser 
utilizado para ler ou para gravar. Depois, o arquivo pode ser 
fechado por GLOSE, que toma o descritor de arquivo dispo¬ 
nível para reutilização em um CREAT ou OPEN subseqüente. 

As chamadas mais utilizadas são, sem dúvida, read e 
WRITE. Vimos READ anteriormente, write tem os mesmos 
parâmetros. 

Embora a maioria dos programas leia e escreva arqui¬ 
vos seqüencialmente, alguns programas aplicativos preci¬ 
sam ser capazes de acessar qualquer parte de um arquivo 
aleatoriamente. Associado a cada arquivo, existe um pon¬ 
teiro que indica a posição atual no arquivo. Quando lendo 
(gravando) seqüencialmente, normalmente ele aponta para 
o próximo byte a ser lido (gravado). A chamada LSEEK muda 
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o valor da posição do ponteiro, de modo que chamadas 
subseqüentes RF.AD ou VíTtlTE podem começar em qualquer 
lugar no arquivo ou até além do fim. 

lsekk tem três parâmetros: o primeiro é o descritor de 
arquivo para o arquivo, o segundo é uma posição de arqui¬ 
vo e o terceiro informa se a posição do arquivo é relativa ao 
começo do arquivo, à posição atual ou ao fim do arquivo. 
0 valor retornado por lseek é a posição absoluta no arqui¬ 
vo depois de mudar o ponteiro. 

Para cada arquivo, o minix monitora o modo do arqui¬ 
vo (arquivo normal, arquivo especial, diretório e assim por 
diante), o tamanho, a data da última modificação e outras 
informações. Os programas podem pedir para ver essas in¬ 
formações via chamadas de sistema STAT e FSTAT. Essas di¬ 
ferem apenas no fato de que a primeira especifica o arqui¬ 
vo por nome, enquanto a última utiliza um descritor de 
arquivo, o que a torna útil para arquivos abertos, especial¬ 
mente entrada-padrão e saída-padrão, cujos nomes podem 
não ser conhecidos. Ambas as chamadas fornecem como 
segundo parâmetro um ponteiro para uma estrutura onde 
as informações estão definidas. A estrutura é mostrada na 
Figura 1-12. 

Ao manipular descritores de arquivo, a chamada DUP é 
ocasionalmente útil. Considere, por exemplo, um progra¬ 
ma que precise fechar a saída-padrão (descritor de arquivo 
1), substituir outro arquivo como saída-padrão, chamar 
uma função que grava uma saída qualquer na saída-pa¬ 
drão e, então, restaurar a situação original. Basta fechar o 
descritor de arquivo 1 e, então, abrir um novo arquivo para 
que o novo arquivo torne-se a saída-padrão (supondo que 
a entrada-padrão, o descritor de arquivo 0, está em uso), 
mas será impossível restaurar a situação original mais tar¬ 
de. 

A solução é primeiro executar a declaração 
fd = dup(1); 

que utiliza a chamada de sistema DUP para alocar um novo 
descritor de arquivo,^, e arranjar para que ele correspon¬ 
da ao mesmo arquivo que a saída-padrão. A saída-padrão, 
então, pode ser fechada e um novo arquivo ser aberto e 
utilizado. Quando chegar o momento de restaurar a situa¬ 


ção original, o descritor de arquivo 1 pode ser fechado e. 
então, 

n = dup (fd); 

executado para atribuir o descritor de arquivo mais baixo, 
a saber, 1, para o mesmo arquivo que fd. Por fim Jd pode 
ser fechado e voltamos ao ponto aonde começamos. 

A chamada DUP tem uma variante que permite a um 
descritor de arquivo arbitrário não-atribuído ser criado para 
referir-se a um dado arquivo aberto. Ele é chamado por 

dup2(fd, fd2); 

onde fd referencia um arquivo aberto e fd2 é o descritor de 
arquivo não-atribuído que é criado para referenciar o mes¬ 
mo arquivo que fd. Assim, se fd referenciar a entrada-pa¬ 
drão (o descritor de arquivo 0) e fd2 for 4, após a chama¬ 
da, os descritores de arquivo 0 e 4 irão referenciar a entra¬ 
da-padrão. 

A comunicação interprocesso no MINIX usa pipes, como 
descrito anteriormente. Quando um usuário digita 

cat filei file2 | sort 

o shell cria um pipe e prepara a saída-padrão do primeiro 
processo gravando no pipe e, assim, a entrada-padrão do 
segundo processo pode ler a partir dele. A chamada de sis¬ 
tema PIPE cria um pipe e retorna dois descritores de arqui¬ 
vo, um para gravar e outro para ler. A chamada é 

pipe (&fd[0]); 

onde fd é uma matriz de dois números inteiros e fd[ 0] é o 
descritor de arquivo para ler e fd[ 1] para gravar. Geral¬ 
mente, um FORK vem em seguida e o pai fecha o descritor 
de arquivo para ler, e o filho fecha o descritor de arquivo 
para gravar (ou vice-versa), assim um processo pode ler o 
pipe e o outro pode gravar nele. 

A Figura 1-13 representa um esqueleto do procedimen¬ 
to que cria dois processos, com a saída do primeiro canali¬ 
zado para o segundo. (Um exemplo mais realista faria ve¬ 
rificação de erro e manipularia argumentos.) Primeiro um 
pipe é criado e, então, o procedimento ramifica-se, eventu¬ 
almente com o pai tornando-se o primeiro processo no pi- 


struct stat { 
short st_dev; 
unsigned short stjno; 
unsigned short st_mode; 
short st_mink; 
short st_uid; 
short st_gid; 
short st_rdev; 
long st_size; 
long st_atime; 
long st_mtime; 
long st_ctime; 


I* dispositivo a quem o nó-i pertence */ 

/* número de nó-i */ 

/* modo palavra */ 

/* número de links */ 

/* id do usuário */ 

/* id do grupo */ 

/* dispositivo principal/secundário para arquivos especiais 
/* tamanho do arquivo */ 

/* data do último acesso */ 

I* data da última modificação */ 

/* data da última alteração no nó-i */ 


Figura 1-12 A estrutura utilizada para retornar as informações para chamadas de sistema stat e FSTAT. No 
código real, nomes simbólicos são utilizados para alguns tipos. 
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#define STDJNPUT 0 
#define STD_OUTPUT 1 

pipeline(process1, process2) 
char ‘processl,*process2; 

{ 

int fd[2]; 

pipe(&fd[0]); 
if (fork() != 0) { 

I* O processo pai executa estas declarações. */ 

close(fd[0]); 

close(STD_OUTPUT); 

dup(fd[1 ]); 

close(fd[1]); 

execlfprocessl, processl, 0); 

} else { 

/* O processo-filho executa estas declarações. */ 

close(fd[1]); 

close(STDJNPUT); 

dup(fd[0]); 

close(fd[Ó]); 

execl(process2, process2, 0); 

} 

} 


/* descritor de arquivo para a entrada-padrão */ 
/* descritor de arquivo para a saída-padrão */ 


/* ponteiros para nomes de programa */ 


/* cria um pipe*! 


I* o processo 1 não precisa ler do pipe */ 

/* prepara para nova saída-padrão *1 
/* saída-padrão definida como fd[1] *1 
/* este descritor de arquivo não é mais necessário */ 


/* o processo 2 não necessita gravar no pipe */ 

I* prepara para nova entrada-padrão */ 

/* entrada-padrão definida como fd [0] */ 

/* este descritor de arquivo não é mais necessário */ 


Figura 1-13 Um esqueleto para configurar um pipeline de dois processos. 


peline e o processo-filho tornando-se o segundo. Como os 
arquivos a serem executados, processl eprocess2, não sa¬ 
bem que são partes de um pipeline *, é essencial que o des¬ 
critor de arquivo seja tratado de modo que a saída-padrão 
do primeiro processo seja o pipe e a entrada-padrão do se¬ 
gundo seja o pipe. O pai primeiro fecha o descritor de ar¬ 
quivo para leitura do pipe. Então, ele fecha a saída-padrão 
e faz uma chamada DUP que permite que o descritor de 
arquivo 1 grave no pipe. É importante saber que DUP sem¬ 
pre retorna o descritor de arquivo mais baixo disponível, 
neste caso, 1. Então, o programa fecha o outro descritor de 
arquivo do pipe. 

Depois da chamada exec, o processo iniciado terá des¬ 
critores de arquivo 0 e 2 inalterados, e o descritor de arqui¬ 
vo 1 para gravar no pipe. 0 código-filho é análogo. 0 parâ¬ 
metro para execl é repetido porque o primeiro é o arquivo a 
ser executado e o segundo é o primeiro parâmetro, que a 
maioria dos programas espera que seja o nome de arquivo. 

A próxima chamada de sistema, IOCTL, é potencialmente 
aplicável a todos os arquivos especiais. Ela é utilizada, por 
exemplo, por drivers de dispositivo de bloco como o driver 
SCSI para controlar dispositivos de fita e de CD-ROM. En¬ 
tretanto, seu uso principal é com arquivos de caractere es¬ 
peciais, principalmente terminais. 0 POSIX define diversas 
funções que a biblioteca traduz em chamadas IOCTL. As fun¬ 
ções de biblioteca tcgetattr e tcsetattr utilizam IOCTL para 
mudar os caracteres utilizados para corrigir erros de digi¬ 
tação no terminal, mudar o modo do terminal, etc. 


'X. de R. Pipeline : canalização. É o canal de comunicação criado por 
um pipe ligando dois processos. 


Modo processado é o modo terminal normal, no qual 
os caracteres de apagamento e de eliminação trabalham 
normalmente, CTRL-S e CTRL-Q podem ser utilizados para 
parar e para iniciar a saída de terminal, CTRL-D significa 
fim de arquivo, DEL gera um sinal de interrupção e CTRL- 
\ gera um sinal de encerramento para forçar um dump de 
núcleo. 

No modo bruto, todas essas funções são desativadas; 
cada caractere é passado diretamente para o programa sem 
nenhum processamento especial. Além disso, no modo bru¬ 
to, uma leitura a partir do terminal dará para o programa 
quaisquer caracteres que foram digitados, até mesmo uma 
linha parcial, em vez de esperar uma linha completa ser 
digitada, como no modo processado. 

0 modo Cbreak é o meio-termo. Os caracteres de apa¬ 
gamento e de eliminação como CTRL-D são desativados 
para edição, mas CTRL-S, CTRL-Q, DEL e CTRLA são ati¬ 
vados. Como no modo bruto, linhas parciais podem ser re¬ 
tornadas ao programa (se a edição entre linhas estiver de¬ 
sativada, não há necessidade de esperar até que uma linha 
inteira seja recebida — o usuário não pode mudar de idéia 
e excluí-la, como pode no modo processado). 

0 POSix não usa os termos processado, bruto e cbreak. 
Na terminologia do POSIX, modo canônico corresponde 
ao modo processado. Nesse modo, há 11 caracteres especi¬ 
ais, e a entrada é por linhas. No modo não-canônico, um 
número mínimo de caracteres a receber e uma medida de 
tempo, especificada em unidades de 1/10 segundo, deter¬ 
mina como uma leitura será satisfeita. Sob o POSIX, há 
muita flexibilidade e vários sinalizadores podem ser defi¬ 
nidos para fazer o modo não-canônico comportar-se como 
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modo cbreak ou modo bruto. Os termos antigos são mais 
descritivos e continuaremos a usá-los informalmente. 

iocti. tem três parâmetros, por exemplo, uma chama¬ 
da para tcsetattr para definir parâmetros terminais resul¬ 
tará em 

iocti (fd.TCSETS, &termios); 

o primeiro parâmetro especifica um arquivo, o segundo, 
uma operação e o terceiro é o endereço da estrutura do P0- 
SIX que contém sinalizadores e a matriz de caracteres de 
controle. Outros códigos de operação podem adiar as mu¬ 
danças até que toda saída tenha sido enviada, fazer com 
que uma entrada não lida seja descartada e retornar os va¬ 
lores atuais. 

A chamada de sistema ACESS é utilizada para determi¬ 
nar se um certo acesso a arquivo é permitido pelo sistema 
de proteção. Ela é necessária, porque alguns programas 
podem executar usando um uíd de um usuário diferente. 
Esse mecanismo de SETUID será descrito mais tarde. 

A chamada de sistema rename é utilizada para dar um 
novo nome a um arquivo. Os parâmetros especificam o 
nome antigo e o novo. 

Por fim, a chamada FCNTi. é utilizada para controlar 
arquivos, mais ou menos análoga à ioctl (i. e., ambas são 
hacks * horríveis). Ela tem várias opções, a mais importan¬ 
te das quais é para bloqueio de arquivo para consulta. Uti¬ 
lizando FCNTI., é possível para um processo bloquear e des¬ 
bloquear partes de arquivos e testar parte de um arquivo 
para ver se ele está bloqueado. A chamada não impõe qual¬ 
quer semântica de bloqueio. Os programas devem fazer isso 
por si mesmos. 

1.4.4 Chamadas de Sistema para 
Gerenciamento de Diretórios 

Nesta seção examinaremos algumas chamadas de sis¬ 
tema que se relacionam mais com diretórios ou com o sis¬ 
tema de arquivos como um todo, em vez de somente com 
um arquivo específico como na seção anterior. As primei¬ 
ras duas chamadas, mkdir e RMD1R, criam e removem di¬ 
retórios vazios, respectivamente. A próxima chamada é LINK. 
Seu propósito é permitir que o mesmo arquivo apareça sob 
dois ou mais nomes, freqüentemente em diretórios dife¬ 
rentes. Um uso típico é permitir que vários membros da 
mesma equipe de programação compartilhem um arqui¬ 
vo comum, com cada um deles tendo o arquivo aparecen¬ 
do no seu próprio diretório, possivelmente sob nomes dife¬ 
rentes. Compartilhar um arquivo não é o mesmo que dar a 
cada membro de equipe uma cópia privada, porque ter um 
arquivo compartilhado significa que alterações feitas por 
qualquer membro da equipe são instantaneamente visí¬ 
veis para os outros membros — há só um arquivo. Quan- 


‘N. de T. Hack - 1. Modificação feita no código de um programa, em 
geral, sem que se dedique o tempo necessário para encontrar uma so¬ 
lução elegante. 2. trabalho malfeito. (Dicionário de Informática. 
Microsoft Press. Rio de Janeiro, Editora Campus, 1998.) 


do são feitas cópias de um arquivo, as mudanças subse¬ 
quentes feitas em uma cópia não têm efeito nas outras. 

Para ver como LINK funciona, considere a situação da 
Figura l-l4(a). Aqui estão dois usuários, ast e jim. cada 
um tendo seus próprios diretórios com alguns arquivos. Se 
ast agora executa um programa que contém a chamada 
de sistema 

link(“/usr/jim/memo”, “/usr/ast/note”); 

o arquivo memo no diretório de jim agora está inserido no 
diretório de ast sob o nome note. Portanto, /usr/jim/memo 
e /usr/ast/note referem-se ao mesmo arquivo. 

O entendimento de como I.1NK funciona provavelmente 
tornará mais claro o que ele faz. Cada arquivo no MINIX 
tem um número único, seu número i, que o identifica. Tal 
número-i é um índice em uma tabela de nós-i, um por 
arquivo, informando quem é o proprietário do arquivo, onde 
seus blocos de disco estão e assim por diante. Um diretório 
é simplesmente um arquivo que contém um conjunto de 
pares (número-i, nome em ASCII). Na Figura 1-14, tnail 
tem 16 como número-i e assim por diante. 0 que link faz é 
simplesmente criar uma nova entrada de diretório com um 
(possivelmente novo) nome, usando o número-i de um 
arquivo existente. Na Figura 1-I4(b), duas entradas têm o 
mesmo número-i (70) e assim referenciam o mesmo ar¬ 
quivo. Se qualquer uma mais tarde for removida, usando a 
chamada de sistema unlink, o outro permanece. Se ambas 
forem removidas, o MiNix vê que nenhuma entrada para o 
arquivo existe (um campo no nó-i monitora o número de 
entradas de diretório que apontam para o arquivo), então 
o arquivo é removido do disco. 

Como mencionamos anteriormente, a chamada de sis¬ 
tema mouxt permite que dois sistemas de arquivos fun¬ 
dam-se em um. Uma situação comum é ter o sistema de 
arquivos-raiz, contendo as versões binárias (executáveis) 
dos comandos comuns e outros arquivos intensamente uti¬ 
lizados, no disco de RAM. O usuário, então, pode inserir 
um disquete, por exemplo, que contém programas de usu¬ 
ário, na unidade 0. 

Executando a chamada de sistema mouxt, o sistema 
de arquivos da unidade 0 pode ser anexado ao sistema de 
arquivos-raiz, como mostrado na Figura 1-15. Uma típica 
declaração em C para executar a montagem é 

mount(“/dev/fdO”, “/mnt”, 0); 

onde o primeiro parâmetro é o nome de um arquivo de 
bloco especial para a unidade 0 e o segundo parâmetro é o 
lugar na árvore onde ele será montado. 

Depois da chamada MOUNT, um arquivo na unidade 0 
pode ser acessado usando apenas seu caminho a partir do 
diretório-raiz ou do diretório de trabalho, sem considerar 
em qual unidade ele está. Aliás, a segunda, a terceira e a 
quarta unidades também podem ser montadas em qual¬ 
quer lugar na árvore. O comando MOUNT torna possível 
integrar mídia removível em uma única hierarquia inte¬ 
grada de arquivos, sem precisar preocupar-se com o dispo¬ 
sitivo em que um arquivo está. Embora esse exemplo en- 
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Figura 1-14 (a) Dois diretórios antes de \'mca\di/usr/jim/memo com o diretório ast. (b) Os mesmos 

diretórios depois da vinculação. 


volva disquetes, também podem ser montados desta ma¬ 
neira discos rígidos ou partes de discos rígidos (frequente¬ 
mente chamadas partições ou dispositivos secundári¬ 
os). Quando um sistema de arquivos não é mais necessá¬ 
rio, ele pode ser desmontado com a chamada de sistema 
1'MOUNT. 

O MiNix mantém um cache de blocos recentemente uti¬ 
lizados na memória principal para evitar precisar lê-los do 
disco se eles forem utilizados de novo rapidamente. Se um 
bloco no cache é modificado (por um write em um arqui¬ 
vo) e o sistema falhar antes do bloco modificado ser grava¬ 
do no disco, o sistema de arquivos será danificado. Para 
limitar o dano potencial, é importantes descarregar o ca¬ 
che periodicamente, de modo que a quantidade de dados 
perdidos por causa de uma falha será pequena. A chamada 
de sistema sync informa o minix para gravar todos os blo¬ 
cos de cache que foram modificados desde que eles foram 
lidos. Quando o MINIX é iniciado, um programa chamado 
update é iniciado como um processo de segundo plano para 
fazer um sync a cada 30 segundos, mantendo o cache lim¬ 
po. 

Duas outras chamadas relacionadas com diretórios são 
CHDIR e CHROOT. A primeira muda o diretório de trabalho e 
a última muda o diretório raiz. Depois da chamada 

chdir (“/usr/ast/test”); 

uma chamada open para o arquivo ,tr.r abrirá /usr/ast/ 
test/xyz. CHROOT funciona de maneira análoga. Uma vez 
que um processo informou o sistema para mudar seu dire¬ 
tório raiz, todo nome de caminho absoluto (nomes de ca¬ 
minho começam com um “/") iniciará na nova raiz. Só 
superusuários podem executar CHROOT e superusuários re¬ 
gulares não o fazem com muita freqüência. 



(a) 


1.4.5 Chamadas de Sistema para 
Proteção 

No minix cada arquivo tem um modo de 11 bits utiliza¬ 
do para proteção, nove dos quais são os bits de leitura-gra- 
vação-execução para o proprietário, para o grupo e para 
outros. A chamada de sistema CHMOD torna possível mudar 
o modo de um arquivo. Por exemplo, para tornar somente 
de leitura um arquivo para todos, exceto o proprietário, 
pode-se executar 

chmod (“file”, 0644); 

Os outros dois bits de proteção, 02000 e 04000. são os 
bits de SETGID ( set-group-id) e SF.TUID (set-user-id) , res¬ 
pectivamente. Quando qualquer usuário executa um pro¬ 
grama com o bit de SETITD ativado, até o fim desse proces¬ 
so o uid efetivo do usuário é mudado para o do proprietá¬ 
rio do arquivo. Esse recurso é intensamente utilizado para 
permitir que os usuários executem programas que reali¬ 
zam funções exclusivas do superusuário, como criar dire¬ 
tórios. A criação de um diretório utiliza mknod, que é ex¬ 
clusiva do superusuário. Arranjando para o programa 
mkdir ser possuído pelo superusuário e ter o modo 04755, 
os usuários normais podem ter o poder de executar MKNOD, 
mas de um modo bastante restrito. 

Quando um processo executa um arquivo que tem o 
bit de SKTUID ou SETGID em seu modo, ele adquire um uid 
ou gid efetivo diferente de seu uid ou gid real. As vezes, ele 
é importante para um processo saber qual é seu uid ou gid 
efetivo e real. As chamadas de sistema GETUID e GETGID fo¬ 
ram fornecidas para proporcionar essas informações. Cada 
chamada retorna o uid ou o gid efetivo e real, então qua¬ 
tro rotinas de biblioteca são necessárias para extrair as in- 



Figura 1-15 (a) Sistema de arquivos antes da montagem, (b) Sistema de arquivos depois da montagem. 
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formações adequadas: getuid. getgid. geteuid ege/egid. As 
duas primeiras recebem o uid/gíd real e as últimas duas os 
efetivos. 

Usuários normais não podem mudar seu uid, exceto 
executando programas com o bit de SETUID ativado, mas o 
superusuário tem outra possibilidade: a chamada de siste¬ 
ma SKTülD. que define os uids real e efetivo. SKTGID define 
os doisg/tífe. O superusuário tambe'm pode mudar o propri¬ 
etário de um arquivo com a chamada de sistema CHOWN. 
Em resumo, o superusuário tem várias oportunidades para 
transgredir todas as regras de proteção, o que explica por 
que tantos estudantes dedicam tanto de seu tempo a tentar 
tornar-se superusuário. 

As últimas duas chamadas de sistema nesta categoria 
podem ser executadas por processos de usuários normais. 
A primeira, UMASK, define uma máscara interna de bits para 
o sistema, que é utilizada para mascarar bits de modo quan¬ 
do um arquivo é criado. Após a chamada 

umask(022); 

o modo fornecido por C.reat e iiknod terá os bits 022 mas¬ 
carados antes de serem utilizados. Assim a chamada 

creat (“file”, 0777); 

definirá o modo para 0755 em vez de 0777. Como a másca¬ 
ra de bit é herdada por processos-filho, se o shell fizer um 
UMASK imediatamente após o login, nenhum dos processos 
de usuário nessa sessão criarão acidentalmente arquivos 
em que outras pessoas podem gravar. 

Quando um programa possuído pela raiz tem o bit de 
SETUID ativado, ele pode acessar qualquer arquivo, porque 
seu uid efetivo é o de superusuário. Freqüentemente é útil 
para o programa saber se a pessoa que chamou o progra¬ 
ma tem permissão para acessar um determinado arquivo. 
Se o programa tentar somente o acesso, ele sempre será 
bem-sucedido e, portanto, não perceberá nada. 

0 que é necessário é uma maneira de ver se o acesso é 
permitido para o uid real. A chamada de sistema ACCF.SS 
fornece uma maneira de sabê-lo. O parâmetro mode é 4 
para verificar acesso de leitura, 2 para acesso de gravação e 
1 para acesso de execução. As combinações também são 
permitidas, por exemplo, com mode igual a 6, a chamada 
retorna 0 se são permitidos acesso de leitura e gravação 
para o uid real; caso contrário, -1 é retornado. Com mode 
igual a 0, uma verificação é feita para ver se o arquivo existe 
e se os diretórios que levam até ele podem ser pesquisados. 

1.4.6 Chamadas de Sistema para 
Gerenciamento de Tempo 

0 MiNix tem quatro chamadas de sistema que envol¬ 
vem o tempo de relógio convencional. TIME retorna a hora 
atual em segundos, com 0 correspondendo a I o de Jan. de 
1970 à meia-noite (exatamente quando o dia está inician¬ 
do, não quando está acabando). Naturalmente, o relógio 
do sistema deve ser configurado em algum ponto para per¬ 
mitir ser lido mais tarde, então STIME foi fornecida para 


permitir que o relógio seja configurado (pelo superusuá¬ 
rio). A terceira chamada de tempo é UTIME, que permite 
que o proprietário de um arquivo (ou o superusuário) mude 
a data/hora armazenada no nó-i do arquivo. A aplicação 
desta chamada de sistema é relativamente limitada, mas 
alguns programas precisam dela como, por exemplo, tou- 
ch, que configura a data/hora do arquivo como a data/ 
hora atual. 

Por fim, temos TIMES, que retoma as informações de 
contagem de um processo, de tal modo que se possa ver 
quanto tempo de CPU ele tem utilizado diretamente e quan¬ 
to tempo de CPU o sistema em si gastou em seu favor (ma¬ 
nipulando suas chamadas de sistema). Os tempos de usu¬ 
ário e de sistema totais utilizados por todos os seus filhos 
combinados também são retornados. 


1.5 A ESTRUTURA DO SISTEMA 
OPERACIONAL 

Agora que vimos como os sistemas operacionais se pa¬ 
recem externamente (i. e., a interface do programador), é 
hora de vê-los por dentro. Nas seções a seguir, examinare¬ 
mos quatro estruturas diferentes que foram experimenta¬ 
das, a fim de obter uma idéia do espectro de possibilidades. 
Essas não são de modo algum exaustivas, mas dão uma 
idéia de alguns modelos que foram experimentados na prá¬ 
tica. Os quatro modelos são sistemas monolíticos, sistemas 
em camadas, máquinas virtuais e sistemas cliente-servidor. 

1.5.1 Sistemas Monolíticos 

Esta é, de longe, a organização mais comum. Esta abor¬ 
dagem poderia muito bem ser subintitulada “A Grande 
Bagunça”. A estrutura é tal que não há nenhuma estrutu¬ 
ra. O sistema operacional é escrito como uma coleção de 
procedimentos, cada um dos quais pode chamar qualquer 
um dos outros sempre que precisar. Quando essa técnica é 
utilizada, cada procedimento no sistema tem uma interfa¬ 
ce bem-definida em termos de parâmetros e de resultados e 
cada um é livre para chamar qualquer um dos outros, se o 
último fornecer alguma computação útil de que o primei¬ 
ro precisa. 

Para construir o programa-objeto do sistema operacio¬ 
nal, quando essa aproximação é utilizada, primeiro deve- 
se compilar todos os procedimentos ou os arquivos indivi¬ 
duais que contêm os procedimentos e, então, agrupá-los 
todos juntos em um único arquivo-objeto usando o link- 
editof do sistema. Em termos de proteção de informações, 
não há essencialmente nenhuma — cada procedimento é 
visível para todos os demais (em oposição a uma estrutura 
contendo módulos ou pacotes, em que muitas das informa- 


*N. de R. Linhedilor. programa que reúne arquivos-objeto compilados 
independentemente, de modo a gerar um arquivo executável. Este pro¬ 
cesso também é referido como vinculação ou montagem ao longo deste 
livro. 
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ções sao ocultas dentro de módulos e só os pontos de entra¬ 
da oficialmente designados podem ser chamados de fora 
do módulo). 

Mesmo em sistemas monolíticos, entretanto, é possível 
ter pelo menos um pouco de estrutura. Os serviços (chama¬ 
das de sistema) fornecidos pelo sistema operacional são re¬ 
quisitados — colocando-se os parâmetros em lugares bem 
definidos, como em registradores ou na pilha e, então, exe¬ 
cutando uma instrução especial de interrupção conhecida 
como chamada de kemel ou chamada de supervisor. 

Essa instrução comuta a máquina do modo usuário 
para modo kemel e transfere o controle para o sistema ope¬ 
racional, mostrado como o evento (1) na Figura 1-16. (A 
maioria das CPUs tem dois modos: modo kemel, para o 
sistema operacional, em que todas as instruções são per¬ 
mitidas, e modo usuário, para programas de usuário, nos 
quais a E/S e outras instruções não são permitidas.) 

0 sistema operacional, então, examina os parâmetros 
da chamada para determinar qual chamada de sistema deve 
ser executada, mostrado como (2) na Figura 1-16. Em se¬ 
guida, o sistema operacional pesquisa em uma tabela que 
contém em uma entrada k um apontador para o procedi¬ 
mento que executa a chamada de sistema k. Essa operação, 
mostrada como (3) na Figura 1-16, identifica o procedi¬ 
mento do serviço, que, então, é chamado. Quando o traba¬ 
lho é completado e a chamada de sistema acaba, o controle 
é devolvido para o programa de usuário (passo 4), de tal 
modo que ele pode continuar a execução com a declaração 
que se segue à chamada de sistema. Essa organização su¬ 
gere uma estrutura básica para o sistema operacional: 

1. Um programa principal que invoca o procedimento 
de serviço requisitado. 


2. Um conjunto de procedimentos de serviços que 
executa as chamadas de sistema. 

3. Um conjunto de procedimentos utilitários que aju¬ 
da os procedimentos de serviços. 

Nesse modelo, para cada chamada de sistema há um 
procedimento de serviço que cuida dela. Os procedimentos 
utilitários fazem coisas que são necessárias para vários pro¬ 
cedimentos de serviço, como buscar dados de programas 
de usuário. Essa divisão dos procedimentos em três cama¬ 
das é mostrada na Figura 1-17. 

1.5.2 Sistemas em Camadas 

Uma generalização da abordagem da Figura 1-17 é or¬ 
ganizar o sistema operacional como uma hierarquia de 
camadas, construídas uma sobre a outra. 0 primeiro siste¬ 
ma construído dessa maneira foi o sistema criado no Tech- 
nische Hogeschool Eindhoven, na Holanda, por E. W. Di- 
jkstra (1968) e seus alunos. 0 sistema THE era um sistema 
de lote simples para um computador holandês, 0 Electro- 
logica X8 , que tinha 32K de palavras de 27 bits (bits eram 
caros naquela época). 

0 sistema tinha seis camadas, como mostrado na Figu¬ 
ra 1-18. A camada 0 lidava com a alocação do processador, 
alternando entre processos quando ocorriam interrupções 
ou quando temporizadores expiravam. Acima da camada 
0, 0 sistema consistia em processos seqüenciais, cada um 
dos quais podia ser programado sem ser necessário preo¬ 
cupar-se com 0 fato de que múltiplos processos estavam 
executando num único processador. Em outras palavras, a 
camada 0 proporcionava a multiprogramação básica da 
CPU. 
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Figura 1 -16 Como uma chamada de sistema pode ser feita: ( 1 ) 0 programa de usuário gera uma interrupção 
parao kemel. (2) 0 sistema operacional determina 0 número do serviço necessário. (3) 0 sistema operacional 
chama 0 procedimento de serviço. (4) 0 controle é retornado para 0 programa de usuário. 
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Figura 1-17 Um modelo simples de estruturação para um sistema monolítico. 


A camada 1 fazia o gerenciamento de memória. Ela 
alocava espaço para processos na memória principal e em 
um tambor* com 512K de palavras utilizado para armaze¬ 
nar partes dos processos (páginas) para os quais não havia 
lugar na memória principal. Acima da camada 1. proces¬ 
sos não tinham que se preocupar com o fato de eles esta¬ 
rem em memória ou no tambor; o software da camada 1 
cuidava de assegurar que as páginas fossem levadas para a 
memória sempre que fossem necessárias. 

A camada 2 manipulava a comunicação entre cada pro¬ 
cesso e o console do operador. Acima dessa camada, cada 
processo efetivamente tinha seu próprio console de opera¬ 
dor. A camada 3 cuidava de gerenciar os dispositivos de E/S 
e de armazenar os fluxos de informação para eles e a partir 
deles. Acima da camada 3, cada processo podia lidar com 
dispositivos abstratos de E/S com propriedades amigáveis, 
em vez de dispositivos reais com muitas peculiaridades. A 


camada 4 era onde os programas de usuário localizavam- 
se. Eles não tinham de preocupar-se com gerenciamento de 
processos, de memória, de console ou de E/S. 0 processo de 
operador do sistema localizava-se na camada 5. 

Uma posterior generalização do conceito de camadas 
estava presente no sistema MULTICS. Em vez de camadas, o 
MULTICS foi organizado como uma série de anéis concên¬ 
tricos, com os internos sendo mais privilegiados do que os 
externos. Quando um procedimento em um anel externo 
queria chamar um procedimento em um anel interno, ele 
tinha de fazer o equivalente de uma chamada de sistema, 
isto é, uma instrução TRAP cujos parâmetros eram cuida¬ 
dosamente verificados quanto à validade antes de permitir 
que a chamada prosseguisse. Embora o sistema operacio¬ 
nal inteiro fosse parte do espaço de endereçamento de cada 
processo de usuário no multics, o hardware tornava possí¬ 
vel designar procedimentos individuais (segmentos de me- 
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Figura 1-18 A estrutura do sistema operacional THE. 


*N. de R. Antigo meio magnético de armazenamento de dados. 
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mória, na realidade) como protegidos contra leitura, gra¬ 
vação ou execução. 

Enquanto o esquema em camadas do THK era realmen¬ 
te só um auxílio para modelagem, porque todas as partes 
do sistema estavam em última instância vinculadas juntas 
em um único programa objeto, no MUI.TICS o mecanismo 
de anel era muito presente em tempo de execução e refor¬ 
çado pelo hardware. A vantagem do mecanismo de anel e' 
que ele podia facilmente ser estendido para estruturar sub¬ 
sistemas de usuário. Por exemplo, um professor podia es¬ 
crever um programa para testar e para avaliar programas 
de aluno e executar esse programa no anel n, com o pro¬ 
grama do aluno sendo executado no anel n + 1 de tal modo 
que eles não podiam mudar seus níveis. 

1.5.3 Máquinas Virtuais 

As versões iniciais do OS /360 eram estritamente sistemas 
de lote. Não obstante, muitos usuários do 360 queriam ter 
tempo compartilhado, assim vários grupos, tanto de den¬ 
tro como de fora da IBM decidiram escrever sistemas de 
tempo compartilhado para ele. O sistema oficial de tempo 
compartilhado da IBM, 0 TSS/ 360 , foi lançado tardiamente; 
quando finalmente chegou, era tão grande e lento que pou¬ 
cos ambientes foram convertidos para ele. Por fim, ele aca¬ 
bou sendo abandonado depois que seu desenvolvimento 
tinha consumido algo em torno de USS 50 milhões 
(Graham, 1970). Mas um grupo no Centro Científico da 
IBM em Cambridge, Massachusetts, produziu um sistema 
radicalmente diferente que a IBM acabou aceitando como 
um produto e que agora é amplamente utilizado em seus 
mainframes remanescentes. 

Esse sistema, originalmente chamado CP/CMS e mais 
tarde rebatizado como VM /370 (Seawright e MacKinnon, 
1979), foi baseado em uma observação astuta: um sistema 
de tempo compartilhado fornece (1) multiprogramação e 
(2) uma máquina estendida com uma interface mais con¬ 
veniente que 0 hardware básico. A essência do VM/370 foi 
separar completamente essas duas funções. 

O coração do sistema, conhecido como monitor de 
máquina virtual, rodava no hardware básico e fazia a 
multiprogramação, oferecendo não uma, mas várias má¬ 
quinas virtuais à camada superior seguinte, como mostra¬ 
do na Figura 1-19- Entretanto, ao contrário de todos os 


outros sistemas operacionais, essas máquinas virtuais não 
são máquinas estendidas, com arquivos e com outros re¬ 
cursos amigáveis. Em vez disso, elas são cópias exatas do 
hardware básico, incluindo 0 modo kernel/usoixxo, E/S, 
interrupções e tudo mais que uma máquina real tem. 

Como cada máquina virtual é idêntica ao hardware 
verdadeiro, cada uma pode executar qualquer sistema ope¬ 
racional que executará diretamente sobre 0 hardware bá¬ 
sico. Máquinas virtuais diferentes podem e frequentemen¬ 
te executam sistemas operacionais diferentes. Algumas exe¬ 
cutam um dos descendentes do OS /360 para processamento 
de transações ou de lotes, enquanto outras executam um 
sistema interativo monousuário chamado CMS (Çonversa- 
tional Monitor System) para usuários de tempo comparti¬ 
lhado. 

Quando um programa CMS executa uma chamada de 
sistema, a chamada é interceptada pelo sistema operacio¬ 
nal da sua própria máquina virtual, não pelo VM/ 370 , exa¬ 
tamente como faria se estivesse executando em uma má¬ 
quina real em vez de em uma virtual. O CMS, então, emite 
as instruções normais de E/S de hardware para ler seu dis¬ 
co virtual, ou 0 que é necessário para executar a chamada. 
Essas instruções de E/S são interceptadas pelo VM/ 370 , que 
então as executa como parte de sua simulação do hardwa¬ 
re real. Fazendo uma separação completa das funções de 
multiprogramação e oferecendo uma máquina estendida, 
cada um dos pedaços pode ser muito mais simples, mais 
flexível e mais fácil de manter. 

A idéia de uma máquina virtual é intensamente utili¬ 
zada hoje em dia em um contexto diferente: executando 
programas antigos de MS-DOS em um Pentium (ou outra 
CPU de 32 bits da Intel). Ao projetar 0 Pentium e seu sof¬ 
tware, tanto a Intel como a Microsoft reconheceram que 
haveria uma grande demanda para executar software an¬ 
tigo no novo hardware. Por essa razão, a Intel ofereceu um 
modo virtual 8086 no Pentium. Assim, a máquina age como 
um 8086 (que é idêntico a um 8088 do ponto de vista do 
software), incluindo 0 endereçamento de 16 bits com um 
limite de 1MB. 

Este modo é utilizado pelo WINDOWS, 0 OS/2 e outros 
sistemas operacionais para executar programas do MS-DOS. 
Esses programas são iniciados no modo 8086 virtual. Con¬ 
tanto que executem instruções normais, eles rodam sobre 
0 hardware básico. Entretanto, quando um programa ten- 
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Figura 1-19 A estrutura do VM/370 com CMS. 
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ta interceptar o sistema operacional para fazer uma cha¬ 
mada de sistema ou tenta fazer E/S protegida diretamente, 
ocorre uma interrupção para o monitor da máquina virtu¬ 
al. 

Duas variantes nesse modelo são possíveis. Na primei¬ 
ra, o próprio MS-DOS é carregado no espaço de endereço 
virtual do 8086, de tal modo que o monitor da máquina 
virtual somente reflete de volta a interrupção para o MS- 
DOS, assim como aconteceria em um 8086 real. Quando o 
MS-DOS mais tarde tenta fazer a E/S sozinho, essa operação 
é capturada e executada pelo monitor da máquina virtual. 

Na outra variante, o monitor da máquina virtual cap¬ 
tura a primeira interrupção e faz a E/S sozinho, desde que 
saiba quais são todas as chamadas de sistema do MS-DOS e, 
portanto, saiba o que cada interrupção deve fazer. Essa va¬ 
riante é menos pura do que a primeira, já que emula ape¬ 
nas o MS-DOS corretamente e não outros sistemas operaci¬ 
onais, como faz a primeira. Por outro lado, ela é muito 
mais rápida, uma vez que elimina o problema de iniciar o 
MS-DOS para fazer a E/S. Uma desvantagem de realmente 
executar o MS-DOS no modo 8086 virtual é que o MS-DOS 
desperdiça muito tempo às voltas com a habilitação de in¬ 
terrupções, processo que deve ser emulado a um custo sig¬ 
nificativo. 

Vale notar que nenhuma dessas abordagens é realmen¬ 
te a mesma do VM/ 370 , uma vez que a máquina sendo emu¬ 
lada não é um Pentium completo, mas apenas um 8086. 
Com 0 sistema VM/370, é possível executar 0 YM/370 em si na 
máquina virtual. Com 0 Pentium, não é possível executar, 
digamos, WINDOWS no 8086 virtual porque nenhuma ver¬ 
são do WINDOWS roda em um 8086; um 286 é 0 mínimo 
mesmo para a versão mais antiga, e a emulação de 286 
não é fornecida (fica só a emulação do Pentium). 

Com 0 VM/370, cada processo de usuário recebe uma 
cópia exata do computador real. Com 0 modo 8086 virtual 
no Pentium, cada processo de usuário recebe uma cópia 
exata de um computador diferente. Dando um passo à fren¬ 
te, pesquisadores do M.I.T. construíram um sistema que dá 
um clone do computador real para cada usuário, mas com 
um subconjunto dos recursos (Engler et ai. 1995). Assim, 
uma máquina virtual poderia receber os blocos de disco de 
0 a 1023 , a seguinte poderia receber os blocos de 1024 a 
2047 e assim por diante. 

Na camada mais inferior, executando em modo de ker¬ 
nel, está um programa chamado exokemel. Seu traba¬ 
lho é atribuir recursos a máquinas virtuais e, então, verifi¬ 
car tentativas de utilizá-los para assegurar-se de que ne¬ 
nhuma máquina está tentando usar recursos de outra. Cada 
máquina virtual no nível do usuário pode executar 0 pró¬ 
prio sistema operacional, como no v.M /370 e nos 8086s vir¬ 
tuais do Pentium, exceto que cada uma é limitada a usar 
só os recursos que ela solicitou e que lhe foram alocados. 

A vantagem do esquema de exokemel e' que ele econo¬ 
miza uma camada de mapeamento. Em outros projetos, 
cada máquina virtual pensa que tem seu próprio disco, com 
blocos que executam de 0 ate' algum máximo, assim 0 
monitor de máquina virtual deve manter tabelas para re- 


mapear endereços de disco (e todos os outros recursos). 
Com 0 exokemel, esse remapeamento não é necessário. O 
exokemel precisa apenas monitorar qual recurso foi desig¬ 
nado a qual máquina virtual. Esse método mantém a van¬ 
tagem de separar a multiprogramação (no exokemel) do 
código do sistema operacional de usuário (no espaço do 
usuário), mas com menor sobrecarga, uma vez que tudo 0 
que 0 exokemel tem de fazer é manter as máquinas virtu¬ 
ais separadas. 

1.5.4 Modelo Cliente-Servidor 

O VM /370 ganha muito em simplicidade, movendo uma 
parte grande do código tradicional do sistema operacional 
(implementando a máquina estendida) para uma cama¬ 
da mais alta, CMS. Entretanto, 0 VM /370 em si continua sen¬ 
do um programa complexo porque simular diversos 370s 
virtuais não é tão simples (especialmente se você quiser 
fazê-lo de maneira razoavelmente eficiente). 

Uma tendência nos sistemas operacionais modernos é 
levar mais adiante ainda essa idéia de mov er có digo para 
camadas mais altas e remover tanto quantopossÍYel do sis¬ 
tema operacional, deixando umjnínimo de kernel. A abor¬ 
dagem normal é implementar a maior parte das funções 
dd~sistema operacional em processos de usuário. Para re¬ 
quisitar um serviço, como ler. um bloco de um arquivo, 
umpiocesso de usuário (agora conhecido como processo 
cliente) envia a requisição para um processo servidor, 
que, então, faz 0 trabalho e remete de volta a resposta. 

Nesse modelo, mostrado na Figura 1-20, tudo que oke r- 
nel faz é gerenciar a com unicação entre clientes e servido- 
_res. Divi dir crs is te ma operacional em parte s, cada uma ge- 
renciando apenas uma faceta do sistema, como serviços de 
arquivo, serviços de processo, serviços de terminal ou servi¬ 
ços de memória, to rna todas as partes pequenas e gerenci¬ 
áveis. Ademais, como todos os servidores executam como 
processos de modo usuário e não em modo kernel, eles não 
têm acesso direto ao hardware. Como consequência, se ocor¬ 
rer um bug no servidor de arquivos, 0 serviço de arquivos 
pode cair, mas isso normalmente não derrubará a máqui¬ 
na inteira. 

Outra vantagem do modelo cliente-servidor é sua adap¬ 
tabilidade para uso em sistemas distribuídos (veja a Figu¬ 
ra 1-2 í)7Se um cliente comunlcmsêcom um servidor en¬ 
viando-lhe mensagens, 0 cliente não precisa saber se a 
mensagem é manipulada localmente na própria máquina 
ou se foi enviada através de uma rede para um servidor em 
uma máquina remota. No que diz respeito ao cliente, a 
mesmacoisa acontece em ambos os casos: uma requisição 
foi enviada e uma resposta voltou. 

0 quadro esboçado acima, de um kernel que manipula 
só 0 transporte de mensagens de clientes para servidores e 
vice-versa, não é completamente realista. Algumas funções 
de sistema operacional (como carregar comandos nos re¬ 
gistradores dos dispositivos de E/S físicos) são difíceis, se 
não impossíveis, de fazer a partir de programas no espaço 
do usuário. Há duas maneiras de lidar com esse problema. 
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Figura 1-20 0 modelo cliente-servidor. 


Uma maneira é ter alguns processos servidores críticos (p. 
ex., os drivers de dispositivo de E/S) executando realmente 
em modo de kernel, com acesso completo a todo o har¬ 
dware, mas ainda comunicando-se com outros processos, 
utilizando o mecanismo normal de mensagem. 

A outra maneira é construir uma quantidade mínima 
de mecanismo no kernel, deixando as decisões políticas 
para os servidores no espaço do usuário. Por exemplo, o 
kernel poderia reconhecer que uma mensagem enviada 
para determinado endereço significa capturar o conteúdo 
dessa mensagem e carregá-lo nos registradores de disposi¬ 
tivo de E/S de algum disco, para iniciar a leitura do mes¬ 
mo. Nesse exemplo, o kernel nem mesmo iria inspecionar 
os bytes na mensagem para ver se são válidos ou significa¬ 
tivos: simplesmente os copiaria cegamente para os regis¬ 
tradores de dispositivo do disco. (Obviamente, deve-se uti¬ 
lizar algum esquema para limitar essas mensagens a pro¬ 
cessos autorizados apenas.) A divisão entre mecanismo e 
política é um conceito importante: ela ocorre repetidamente 
em sistemas operacionais em diversos contextos. 

1.6 VISÃO GERAL DO RESTANTE 
DESTE LIVRO 

Os sistemas operacionais tipicamente têm quatro gran¬ 
des componentes: gerenciamento de processos, gerencia¬ 
mento de dispositivos de E/S, gerenciamento de memória e 


Máquina 1 Máquina 2 



gerenciamento de arquivos. 0 MINIX também é dividido 
nessas quatro partes. Os próximos quatro capítulos tratam 
desses quatro temas, um por capítulo. 0 Capítulo 6 contêm 
uma lista de leituras sugeridas e uma bibliografia. 

Os capítulos sobre processos, E/S, gerenciamento de 
memória e sistema de arquivos têm a mesma estrutura 
geral. Primeiro são expostos os princípios gerais do assun¬ 
to. Então, é apresentada uma visão geral da área corres¬ 
pondente do MINIX (que também se aplica ao UNIX). Por 
fim, a implementação do minix é discutida em detalhe. A 
seção de implementação pode ser vista superficialmente ou 
até pulada sem perda de continuidade para leitores inte¬ 
ressados apenas nos princípios dos sistemas operacionais e 
não no código do MINIX. [Leitores interessados em saber 
como um sistema operacional real (o minix) funciona de¬ 
vem ler todas as seções.] 


1.7 RESUMO 

Os sistemas operacionais podem ser vistos de dois pon¬ 
tos de vista: gerenciadores de recursos e máquinas estendi¬ 
das. Na visão de gerenciador de recurso, o trabalho do sis¬ 
tema operacional é gerenciar eficientemente as diferentes 
partes do sistema. Na visão de máquina estendida, o traba¬ 
lho do sistema é oferecer aos usuários uma máquina virtu¬ 
al que é mais conveniente para usar do que a máquina 
real. 
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Figura 1-21 0 modelo cliente-servidor em um sistema distribuído. 
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Uma maneira é ter alguns processos servidores críticos (p. 
ex., os drivers de dispositivo de E/S) executando realmente 
em modo de kernel , com acesso completo a todo o har¬ 
dware, mas ainda comunicando-se com outros processos, 
utilizando o mecanismo normal de mensagem. 

A outra maneira é construir uma quantidade mínima 
de mecanismo no kernel, deixando as decisões políticas 
para os servidores no espaço do usuário. Por exemplo, o 
kernel poderia reconhecer que uma mensagem enviada 
para determinado endereço significa capturar o conteúdo 
dessa mensagem e carregá-lo nos registradores de disposi¬ 
tivo de E/S de algum disco, para iniciar a leitura do mes¬ 
mo. Nesse exemplo, o kernel nem mesmo iria inspecionar 
os bytes na mensagem para ver se são válidos ou significa¬ 
tivos: simplesmente os copiaria cegamente para os regis¬ 
tradores de dispositivo do disco. (Obviamente, deve-se uti¬ 
lizar algum esquema para limitar essas mensagens a pro¬ 
cessos autorizados apenas.) A divisão entre mecanismo e 
política é um conceito importante: ela ocorre repetidamente 
em sistemas operacionais em diversos contextos. 

1.6 VISÃO GERAL DO RESTANTE 
DESTE LIVRO 

Os sistemas operacionais tipicamente têm quatro gran¬ 
des componentes: gerenciamento de processos, gerencia¬ 
mento de dispositivos de E/S, gerenciamento de memória e 
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gerenciamento de arquivos. 0 MINIX também é dividido 
nessas quatro partes. Os próximos quatro capítulos tratam 
desses quatro temas, um por capítulo. 0 Capítulo 6 contêm 
uma lista de leituras sugeridas e uma bibliografia. 

Os capítulos sobre processos, E/S, gerenciamento de 
memória e sistema de arquivos têm a mesma estrutura 
geral. Primeiro são expostos os princípios gerais do assun¬ 
to. Então, é apresentada uma visão geral da área corres¬ 
pondente do MINIX (que também se aplica ao UNIX). Por 
fim, a implementação do MINIX é discutida em detalhe. A 
seção de implementação pode ser vista superficialmente ou 
até pulada sem perda de continuidade para leitores inte¬ 
ressados apenas nos princípios dos sistemas operacionais e 
não no código do MINIX. [Leitores interessados em saber 
como um sistema operacional real (o minix) funciona de¬ 
vem ler todas as seções.] 

1.7 RESUMO 

Os sistemas operacionais podem ser vistos de dois pon¬ 
tos de vista: gerenciadores de recursos e máquinas estendi¬ 
das. Na visão de gerenciador de recurso, o trabalho do sis¬ 
tema operacional é gerenciar eficientemente as diferentes 
partes do sistema. Na visão de máquina estendida, o traba¬ 
lho do sistema é oferecer aos usuários uma máquina virtu¬ 
al que é mais conveniente para usar do que a máquina 
real. 
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Figura 1-21 0 modelo cliente-servidor em um sistema distribuído. 
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Os sistemas operacionais têm uma longa história, ini¬ 
ciando na e'poca em que substituíram o operador até os 
modernos sistemas de multiprogramação. 

0 coração de qualquer sistema operacional é o conjun¬ 
to de chamadas de sistema que ele pode gerenciar. Essas 
informam o que o sistema operacional realmente faz. Para 
o MINTX, essas chamadas podem ser divididas em seis gru¬ 
pos. 0 primeiro grupo de chamadas de sistema está relaci¬ 
onado com a criação e com o encerramento de processos. 


O segundo grupo manipula sinais. O terceiro grupo é para 
ler e para gravar arquivos. Um quarto grupo é para geren¬ 
ciamento de diretório. O quinto grupo protege informa¬ 
ções, e o sexto grupo monitora o tempo. 

Os sistemas operacionais podem ser estruturados de 
vários modos. Os mais comuns são como um sistema mo¬ 
nolítico, como uma hierarquia de camadas, como um sis¬ 
tema de máquina virtual e o uso do modelo cliente-servi¬ 
dor. 


EXERCÍCIOS 


1. Quais são as duas principais funções de um sistema opera¬ 
cional? 

2. O que é multiprogramação? 

3. O que éspooling? Você acredita que os computadores pesso¬ 
ais avançados terão spooling como um recurso padrão no 
futuro? 

4. Nos primeiros computadores, cada byte de dados lido ou es¬ 
crito era diretamente tratado pela CPU (i. e., não havia DMA 
— acesso direto à memória). Que implicações esse arranjo 
tem para a multiprogramação? 

5. Por que o tempo compartilhado não é comum em compu¬ 
tadores de segunda geração? 

6 . Quais das seguintes instruções devem ser permitidas apenas 
no modo de kernel ? 

(a) Desativar todas interrupções. ■ 

(b) Ler o relógio de hora do dia. 

(c) Configurar o relógio de hora do dia. 

(d) Mudar o mapeamento da memória. - 

7. Relacione algumas diferenças entre sistemas operacionais 
de computadores pessoais e sistemas operacionais de main- 
frame. 

8. Um arquivo de minix cujo proprietário tem uid = 12 e gid 
= 1 tem modo rwxr-x—. Outro usuário com uid = 6, gid = 
1 tenta executar o arquivo. O que acontecerá? 

9. Em vista do fato de que a mera existência de um superusuá- 
rio pode levar a todo tipo de problemas de segurança, por 
que tal conceito existe? 


10. 0 modelo cliente-servidor é popular em sistemas distribuí¬ 
dos. Ele também pode ser utilizado em um sistema de um 
único computador? 

11. Por que a tabela de processos é necessária em um sistema de 
tempo compartilhado? Ela também é necessária em siste¬ 
mas de computadores pessoais em que só um processo exis¬ 
te e toma conta da máquina inteira até que se encerre’ 

12. Qual é a diferença essencial entre um arquivo especial de 
bloco e um arquivo especial de caractere? 

13. No MINIX, se o usuário 2 cria um vínculo para um arquivo 
possuído pelo usuário 1, e, então, o usuário 1 remove esse 
arquivo, o que acontece quando o usuário 2 tentar ler o ar¬ 
quivo? 

14. Por que a chamada de sistema de chroot é limitada ao su- 
perusuário? (Sugestão: pense nos problemas de proteção.) 

15. Por que o MINIX tem o programa updcde executando em 
segundo plano o tempo todo? 

16. Faz qualquer sentido ignorar o sinal SIGALRM? 

17. Escreva um programa (ou uma série de programas) testan¬ 
do todas as chamadas de sistema do MINIX. Para cada cha¬ 
mada, tente vários conjuntos de parâmetros, incluindo al¬ 
guns incorretos, para ver se eles são detectados. 

18. Escreva um shell semelhante ao da Figura 1-10 mas conten¬ 
do código suficiente para realmente funcionar de modo que 
você, então, possa testá-lo. Você também poderia adicionar 
alguns recursos tal como redirecionamento de entrada e sa- 
ída .pípes e jobs em segundo plano. 




Processos 


Estamos agora prestes a entrar em um estudo detalha¬ 
do sobre como os sistemas operacionais em geral, e o minix 
em particular, são projetados e construídos. 0 conceito mais 
central em qualquer sistema operacional é o de processo : 
uma abstração de um programa em execução. Tlido mais 
gira em torno desse conceito e é importante que o projetis¬ 
ta de sistema operacional (e o estudante) saiba o que é um 
processo o mais cedo possível. 

2.1 INTRODUÇÃO AOS PROCESSOS 

Todos os computadores modernos podem fazer várias 
coisas ao mesmo tempo. Enquanto executa um programa 
do usuário, um computador também pode estar lendo a 
partir de um disco e dando saída a texto para uma tela ou 
impressora. Em um sistema de multiprogramação, a CPU 
também alterna de um programa para outro, executando 
cada um por dezenas ou centenas de milissegundos. En¬ 
quanto, estritamente falando, em qualquer instante de tem¬ 
po, a CPU está executando só um programa, no curso de 1 
segundo, ela pode funcionar para vários programas, dan¬ 
do aos usuários a ilusão de paralelismo. As vezes, as pesso¬ 
as falam de pseudoparalelismo querendo referir-se a essa 
rápida alternância da CPU entre programas, em contraste 
com o paralelismo verdadeiro em hardware dos sistemas 
multiprocessadores (que têm duas ou mais CPUs com¬ 
partilhando a mesma memória física). Monitorar múlti¬ 
plas atividades paralelas é um problema complicado. As¬ 
sim, com os anos, os projetistas de sistemas operacionais 
desenvolveram um modelo (processos seqüenciais) que 
toma o paralelismo mais fácil de tratar. Esse modelo e suas 
aplicações são o assunto deste capítulo. 


2.1.1 Modelo de Processo 

Neste modelo, todo o software executável no computa¬ 
dor, freqüentemente incluindo o sistema operacional, é 
organizado em um número de processos seqüenciais, 
ou somente processos para simplificar. Um processo é um 
programa em execução, incluindo os valores atuais do con¬ 
tador de programa, registradores e variáveis. Conceitual- 
mente, cada processo tem sua própria CPU virtual. Na rea¬ 
lidade, naturalmente, a CPU alterna de um processo para 
outro, mas, para entender o sistema, é muito mais fácil 
pensar em uma coleção de processos que executam em 
(pseudo)paralelo do que tentar acompanhar como a CPU 
alterna de um programa para outro. Essa rápida alternân¬ 
cia é chamada multiprogramação, como vimos no capí¬ 
tulo anterior. 

Na Figura 2-1 (a), vemos um computador multiprogra- 
mado com quatro programas na memória. Na Figura 2- 
1 (b), vemos quatro processos, cada um com seu próprio 
fluxo de controle (i. e., seu próprio contador de programa) 
e cada um executando independentemente dos outros. Na 
Figura 2-1 (c), vemos que, a partir de um determinado tem¬ 
po, todos os processos fizeram progresso, mas em um dado 
instante só um processo realmente está executando. 

Com a CPU alternando entre os processos, a velocidade 
em que um processo executa sua computação não será 
uniforme e provavelmente nem mesmo reproduzível se os 
mesmos processos forem executados novamente. Assim, os 
processos não devem ser programados com suposições ba¬ 
seadas na coordenação. Considere, por exemplo, um pro¬ 
cesso de E/S que inicia uma fita de streamer para restau¬ 
rar um backup de arquivos, executa um laço de espera 
10.000 vezes para permitir que ela termine o trabalho e, 
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Um contador de programa 



Tempo ■ 


(a) (b) (c) 

Figura 2-1 (a) Multiprogramação de quatro programas, (b) Modelo conceituai de quatro processos seqüenciais independentes, (c) 

Só um programa está ativo em qualquer dado instante. 


então, dá um comando para ler o primeiro registro. Se a 
CPU decidir alternar para outro processo durante o laço de 
espera, o processo da fita pode não executar novamente até 
que o primeiro registro passe pela cabeça de leitura. Quan¬ 
do um processo tem requisitos de tempo real críticos como 
esse (i. e., eventos particulares devem ocorrer dentro de 
um número especificado de milissegundos) medidas espe¬ 
ciais devem ser tomadas para assegurar que isso ocorra. 
Normalmente, entretanto, a maioria dos processos não é 
afetada pela multiprogramação subjacente da CPU, nem 
pelas velocidades relativas dos diferentes processos. 

A diferença entre um processo e um programa é sutil, 
mas crucial. Uma analogia pode ajudar a tornar mais cla¬ 
ra essa questão. Considere um cientista de computador com 
dotes culinários que está assando um bolo de aniversário 
para sua filha. Ele tem uma receita de bolo de aniversário 
e uma cozinha bem-equipada com a entrada necessária: 
farinha, ovos, açúcar, essência de baunilha, etc. Nessa ana¬ 
logia, a receita é o programa (i. e., um algoritmo expresso 
em alguma notação conveniente), o cientista de computa¬ 
dor é o processador (CPU) e os ingredientes do bolo são os 
dados de entrada. 0 processo é a atividade que consiste em 
nosso confeiteiro ler a receita, buscar os ingredientes e co¬ 
zinhar o bolo. 

Agora imagine que o filho do cientista apareça choran¬ 
do, dizendo que foi picado por uma abelha. 0 cientista re¬ 
gistra onde estava na receita (o estado do processo atual é 
salvo), procura um livro de pronto-socorro e começa a se¬ 
guir as orientações nele. Aqui vemos o processador alter¬ 
nando de um processo (cozimento) para um processo de 
prioridade mais alta (administrar cuidado médico), cada 
um tendo um programa diferente (receita versus livro de 
pronto-socorro). Quando a picada de abelha foi tratada, o 
cientista volta ao seu bolo, para continuar a partir do pon¬ 
to onde ele estava quando abandonou o processo. 

A idéia-chave aqui é que um processo é um tipo de ati¬ 
vidade. Ele tem um programa, entrada, saída e um estado. 
Um único processador pode ser compartilhado entre vários 
processos, com algum algoritmo de agendamento sendo 
utilizado para determinar quando parar de trabalhar em 
um processo e servir a um diferente. 


Hierarquias de Processos 

Os sistemas operacionais que suportam o conceito de 
processo devem fornecer alguma maneira de criar todos os 
processos necessários. Em sistemas muito simples, ou em 
sistemas projetados para executar um único aplicativo (p. 
ex., controlar um dispositivo em tempo real), é possível ter 
todos os processos que serão necessários alguma vez logo 
que o sistema inicia. Na maioria dos sistemas, entretanto, 
é preciso dispor de alguma maneira de criar e de destruir 
processos conforme necessário durante a operação. No mi- 
NIX, os processos são criados pela chamada de sistema FORK, 
que cria uma cópia idêntica do processo que fez a chama¬ 
da. O processo-filho também pode executar FORK, então, 
também é possível obter uma árvore inteira de processos. 
Em outros sistemas operacionais existem chamadas de sis¬ 
tema para criar um processo, para carregar sua memória e 
para começar a rodar. Qualquer que seja a natureza exata 
da chamada de sistema, os processos precisam dispor de 
uma maneira de criar outros processos. Note que cada pro¬ 
cesso tem um pai, mas zero, um, dois ou mais filhos. 

Como um exemplo simples do modo como as árvores 
de processo são utilizadas, mostremos o que acontece quan¬ 
do o MINTX é inicializado. Um processo especial, chamado 
init está presente na imagem de inicialização. Quando co¬ 
meça a rodar, ele lê um arquivo, informando quantos ter¬ 
minais existem. Então, ele cria um novo processo por ter¬ 
minal. Esses processos esperam alguém efetuar login. Se 
um login é bem-sucedido, o processo de login executa um 
shell para receber comandos. Esses comandos podem ini¬ 
ciar mais processos, etc. Assim, todos os processos no siste¬ 
ma inteiro pertencem a uma única árvore, com init na 
raiz. 

Estados de um Processo 

Embora cada processo seja uma entidade independen¬ 
te, com seu próprio contador de programa e estado inter¬ 
no, os processos freqüentemente precisam interagir entre 
si. Um processo pode gerar alguma saída que outro proces¬ 
so utiliza como entrada. No comando de shell 
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cat chapterl chapter2 chapters3 | grep tree 

o primeiro processo, executando cat, dá saída a três arqui¬ 
vos concatenados. O segundo processo, executando grep, 
seleciona todas as linhas que contêm a palavra “tree”. De¬ 
pendendo das velocidades relativas dos dois processos (que 
dependem da complexidade relativa dos programas e de 
quanto de tempo de CPU cada um teve), pode acontecer 
que grep esteja pronto para executar, mas não haja ne¬ 
nhuma entrada esperando por ele. Ele deve, então, blo¬ 
quear até que alguma entrada esteja disponível. 

Quando um processo bloqueia, ele faz isso porque logi¬ 
camente ele não pode continuar, em geral, porque está es¬ 
perando uma entrada que ainda não está disponível. Tam¬ 
bém é possível que um processo, que está conceitualmente 
pronto e capaz de executar, seja interrompido porque o sis¬ 
tema operacional decidiu dedicar a CPU a outro processo 
temporariamente. Essas duas condições são completamente 
diferentes. No primeiro caso, a suspensão é inerente ao pro¬ 
blema (você não pode processar a linha de comando do 
usuário até que ele a tenha digitado). No segundo caso, é 
um aspecto técnico do sistema (falta de CPUs suficientes 
para dar a cada processo seu próprio processador). Na Fi¬ 
gura 2-2, vemos um diagrama de estados que mostra os 
três estados em que um processo pode estar: 

1. Executando (realmente utilizando a CPU nesse 
instante). 

2. Pronto (executável; temporariamente parado para 
permitir que outro processo execute). 

3. Bloqueado (incapaz de executar até que algum 
evento externo aconteça). 

Logicamente, os dois primeiros estados são semelhan¬ 
tes. Nos dois casos, o processo está pronto para executar, só 
que no segundo, não há nenhuma CPU disponível para ele 
temporariamente. 0 terceiro estado é diferente dos primei¬ 
ros dois porque o processo não pode executar, mesmo que 
a CPU não tenha mais nada a fazer. 

Quatro transições são possíveis entre esses três estados, 
conforme mostrado. A transição 1 ocorre quando um pro¬ 
cesso descobre que não pode continuar. Em alguns siste¬ 
mas, o processo deve executar uma chamada de sistema, 
BLOCK, para entrar no estado bloqueado. Em outros siste¬ 
mas, incluindo o MINIX, quando um processo lê de um pipe 
ou de um arquivo especial (p. ex., um terminal) e não há 



Figura 2-2 Um processo pode estar em execução, 
estados são como mostradas. 


nenhuma entrada disponível, o processo é automaticamen¬ 
te bloqueado. 

As transições 2 e 3 são causadas pelo agendador de pro¬ 
cessos, uma parte do sistema operacional, sem que o pro¬ 
cesso nem mesmo saiba delas. A transição 2 ocorre quando 
o agendador decide que o processo em execução atuou por 
tempo suficiente e permite que outro processo tenha al¬ 
gum tempo da CPU. A transição 3 ocorre quando todos os 
outros processos tiveram sua justa parte e é hora de o pri¬ 
meiro deles receber a CPU para executar novamente. 0 
agendamento, isto é, decidir que processos devem executar 
quando e por quanto tempo é um assunto importante; ire¬ 
mos examiná-lo mais adiante neste capítulo. Muitos algo¬ 
ritmos foram estudados para tentar equilibrar as deman¬ 
das de requisição por eficiência para o sistema como um 
todo e a imparcialidade para os processos individuais. 

A transição 4 ocorre quando o evento externo pelo qual 
um processo está esperando (como a chegada de alguma 
entrada) acontecer. Se nenhum outro processo está execu¬ 
tando nesse instante, a transição 3 será ativada imediata¬ 
mente e o processo começará a executar. Em vez disso, ele 
pode ter de esperar em estado pronto por alguns instantes 
até que a CPU esteja disponível. 

Usando o modelo de processos, torna-se muito mais fá¬ 
cil pensar no que está ocorrendo dentro do sistema. Alguns 
processos executam programas que executam comandos 
digitados por um usuário. Outros processos são parte do 
sistema e gerenciam tarefas como executar requisições de 
serviços de arquivo ou gerenciar os detalhes de operação 
de um disco ou de uma unidade de fita. Quando ocorre 
uma interrupção de disco, o sistema decide parar de exe¬ 
cutar o processo atual e executar o processo de disco, que 
foi bloqueado para esperar essa interrupção. Assim, em vez 
de pensar nas interrupções, podemos pensar em processos 
de usuário, em processos de disco, em processos de termi¬ 
nal e assim por diante, que bloqueiam quando estão espe¬ 
rando algo acontecer. Quando o bloco de disco foi lido ou o 
caractere digitado, o processo em espera é desbloqueado e 
é elegível para executar novamente. 

Essa visão dá origem ao modelo mostrado na Figura 2- 
3. Aqui, o nível mais baixo do sistema operacional é o agen¬ 
dador, com uma variedade de processos nele. Todo o ge¬ 
renciamento de interrupções e os detalhes sobre como re¬ 
almente iniciar e parar processos são ocultados do agen¬ 
dador, que é realmente bem pequeno. O restante do siste- 


1.0 processo bloqueia para entrada 
2.0 agendador seleciona outro processo 
3.0 agendador seleciona esse processo 

4. A entrada torna-se disponível 


em estado bloqueado ou pronto. As transições entre esses 
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Processos 
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. . . 

n-2 

n -1 

Agendador 


Figura 2-3 A camada mais baixa de um sistema operacional estruturado em processos 
gerencia interrupções e agendamento. Acima dessa camada, estão os processos seqüenciais. 


ma operacional e' elegantemente estruturado na forma de 
processos. 0 modelo da Figura 2-3 é utilizado no MINIX, 
com o entendimento de que “agendador" realmente não 
significa apenas agendamento de processos, mas também 
o gerenciamento de interrupções e toda a comunicação in- 
terprocesso. Mas, como uma primeira abordagem, serve 
para mostrar a estrutura básica. 

2.1.2 Implementação de Processos 

Para implementar o modelo de processos, o sistema ope¬ 
racional mantém uma tabela (uma matriz de estruturas), 
chamada tabela de processos, com uma entrada por pro¬ 
cesso. Essa entrada contém as informações sobre o estado 
do processo, sobre seu contador de programa, sobre o pon¬ 
teiro da pilha, sobre a alocação de memória, sobre o status 
de seus arquivos abertos, sobre suas informações de conta¬ 
bilidade e sobre agendamento e tudo mais sobre o processo 
que deve ser salvo quando o processo alterna de um estado 
em execução ç>zràpronto a fim de que possa ser reiniciado 
mais tarde como se nunca tivesse sido interrompido. 

No MINIX, o gerenciamento de processos, o gerencia¬ 
mento de memória e o gerenciamento de arquivo são tra¬ 


tados por módulos separados dentro do sistema, então, a 
tabela de processos é particionada, com cada módulo man¬ 
tendo os campos de que precisa. A Figura 2-4 mostra al¬ 
guns campos mais importantes. Os campos na primeira 
coluna são os únicos relevantes para este capítulo. As ou¬ 
tras duas colunas são fornecidas somente para dar uma 
idéia das informações que são necessárias em outras par¬ 
tes no sistema. 

Agora que vimos a tabela de processos, é possível expli¬ 
car um pouco mais sobre como a ilusão de múltiplos pro¬ 
cessos seqüenciais é mantida em uma máquina com uma 
CPU e muitos dispositivos de E/S. As técnicas a seguir são 
uma descrição de como o “agendador" da Figura 2-3 fun¬ 
ciona no MINIX, mas a maioria dos sistemas operacionais 
modernos funciona essencialmente da mesma maneira. 
Associado a cada classe de dispositivo de E/S (p. ex., dis¬ 
quetes, discos rígidos, temporizadores, terminais), existe 
uma área próxima à parte inferior da memória chamada 
vetor de interrupção. Ele contém o endereço do procedi¬ 
mento de serviço da interrupção. Suponha que o processo 
de usuário 3 esteja executando quando ocorre uma inter¬ 
rupção de disco. 0 contador do programa, a palavra de sta¬ 
tus do programa e possivelmente um ou mais registradores 


Gerenciamento de processos 

Registradores 

Contador do programa 

Palavra de status do programa 

Ponteiro de pilha 

Estado do processo 

Tempo em que o processo iniciou 

Tempo de CPU utilizado 

Tempo de CPU dos filhos 

Tempo do próximo alarme 

Ponteiros de fila de mensagem 

Bits de sinal pendente 

ld do processo 

Vários bits de sinalização 


Gerenciamento de memória 

Ponteiro para segmento de texto 

Ponteiro para segmento de dados 

Ponteiro para segmento bss 

Status de saída 

Status de sinal 

ld do processo 

Processo-Pai 

Grupo do processo 

Uid real 

Uid efetivo 

Gid real 

Gid efetivo 

Mapas de bit para sinais 
Vários bits de flag 


Gerenciamento de arquivos 

Máscara UMASK 
Diretório-raiz 
Diretório de trabalho 
Descritores de arquivo 
Uid efetivo 
Gid efetivo 

Parâmetros de chamada de sistema 
Vários bits de sinalização 


Figura 2-4 Alguns campos da tabela de processos do MINIX. 
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são enviados para a pilha (atual) pelo hardware de inter¬ 
rupção. O computador, então, salta para o endereço espe¬ 
cificado no vetor de interrupção de disco. Isso é tudo o que 
o hardware faz. Daqui em diante, é com o software. 

0 procedimento de serviço de interrupção inicia salvan¬ 
do todos os registradores na entrada da tabela de processos 
para o processo atual. O número do processo atual e um 
ponteiro para sua entrada são mantidos em variáveis glo¬ 
bais de modo que possam ser localizados rapidamente. En¬ 
tão, as informações depositadas pela interrupção são remo¬ 
vidas da pilha, e o ponteiro da pilha é modificado para apon¬ 
tar para a pilha temporária utilizada pelo gerenciador de 
processos. Ações como salvar os registradores e definir o 
ponteiro da pilha não podem nem mesmo ser expressas em 
C, então, são executados por uma pequena rotina de lin¬ 
guagem assembly. Quando essa rotina termina, ela chama 
um procedimento em C para fazer o resto do trabalho. 

A comunicação interprocesso no MINIX ocorre via men¬ 
sagens; então, o próximo passo é construir uma mensa¬ 
gem a ser enviada para o processo de disco, que será blo¬ 
queado esperando por ele. A mensagem diz que uma inter¬ 
rupção ocorreu para distingui-la de mensagens de proces¬ 
sos de usuário solicitando que blocos de disco sejam lidos e 
coisas semelhantes. 0 estado do processo de disco agora 
está mudado de bloqueado para pronto e o agendador é 
chamado. No MINIX processos diferentes têm prioridades 
diferentes, para dar melhor serviço aos manipuladores de 
dispositivo de E/S do que aos processos de usuário. Se o 
processo de disco agora é o processo executável de priori¬ 
dade mais alta, ele será agendado para executar. Se o pro¬ 
cesso que foi interrompido é igualmente ou mais impor¬ 
tante, então, ele será agendado para executar novamente e 
o processo de disco terá de esperar alguns instantes. 

De qualquer modo, o procedimento em C chamado pelo 
código de interrupção em linguagem assembly agora re¬ 
torna, e o código em linguagem assembly carrega os re¬ 
gistradores e o mapa de memória para o agora atual pro¬ 
cesso e inicia sua execução. 0 gerenciamento e o agenda- 
mento de interrupções estão resumidos na Figura 2-5. Vale 
notar que os detalhes variam ligeiramente de um sistema 
para outro. 


2.1.3 Threads 

Em um processo tradicional, do tipo que acabamos de 
estudar, há uma única linha de controle e um único con¬ 
tador de programa em cada processo. Entretanto, em al¬ 
guns sistemas operacionais modernos, é fornecido suporte 
para múltiplas linhas de controle dentro de um processo. 
Essas linhas de controle normalmente são chamadas thre¬ 
ads ou, ocasionalmente, processos leves. 

Na Figura 2-6(a) vemos três processos tradicionais. Cada 
processo tem seu próprio espaço de endereço e uma única 
linha de controle. Em contraste, na Figura 2-6(b), vemos 
um único processo com três linhas de controle. Embora 
em ambos os casos tenhamos três threads. na Figura 2- 
6(a) cada um deles opera em um espaço diferente de ende¬ 
reço, enquanto na Figura 2-6(b) todos os três comparti¬ 
lham o mesmo espaço de endereço. 

Como um exemplo de onde múltiplos threads podem 
ser utilizados, considere um processo de servidor de arqui¬ 
vos. Ele recebe requisições para ler e para gravar arquivos e 
envia de volta os dados requisitados ou aceita os dados atu¬ 
alizados. Para melhorar o desempenho, o servidor man- 
te'm um cache de arquivos recentemente utilizados em me¬ 
mória, lendo do cache e gravando nele quando possível. 

Essa situação serve bem para o modelo da Figura 2- 
6(b). Quando uma requisição entra, ela é passada a um 
thread para processamento. Se esse //;re«r/bloqueia no meio 
do caminho para esperar uma transferência de disco, ou¬ 
tros threads são ainda capazes de executar, assim, o servi¬ 
dor pode continuar processando novas requisições, mesmo 
quando está ocorrendo E/S de disco. 0 modelo da Figura 
2-6(a) não é adequado, porque é essencial que todos os 
threads do senador de arquivos acessem o mesmo cache e 
os três threads da Figura 2-6(a) não compartilham o mes¬ 
mo espaço de endereço e, portanto, não podem comparti¬ 
lhar o mesmo cache de memória. 

Outro exemplo de onde threads são úteis está nos nave¬ 
gadores para a World Wide Web, como o Netscape e o Mo- 
saic. Muitas páginas da Web contêm várias pequenas ima¬ 
gens. Para cada imagem em uma página da Web, o nave¬ 
gador deve configurar uma conexão separada com o site 


1. O hardware empilha o contador de programa, etc. 

2. O hardware carrega um novo contador de programa a partir do vetor de interrupção. 

3. O procedimento em linguagem assembly salva os registradores. 

4. O procedimento em linguagem assembly define uma nova pilha. 

5. O serviço interrupção em C executa (em geral, lê e armazena a entrada). 

6. O agendador marca a tarefa em espera como pronta. 

7. O agendador decide qual processo será executado em seguida. 

8. O procedimento em C retorna para o código assembly. 

9. O procedimento de linguagem assembly inicia processo atual de novo. 


Figura 2-5 0 esqueleto do que faz o nível mais baixo do sistema operacional quando ocorre uma interrupção. 
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Figura 2-6 (a) Três processos, cada um com um thread. (b) Um processo com três threads. 


da página e requisitar a imagem. Muito tempo é desperdi¬ 
çado, estabelecendo e liberando todas essas conexões. Por 
ter múltiplos threads dentro do navegador, muitas ima¬ 
gens podem ser solicitadas ao mesmo tempo, acelerando 
significativamente o desempenho na maioria dos casos, 
uma vez que com imagens pequenas, o tempo de configu¬ 
ração é o fator limitante, não a velocidade da linha de trans¬ 
missão. 

Quando múltiplos threads estão presentes no mesmo 
espaço de endereço, alguns dos campos da Figura 2-4 não 
são por processo, mas por thread , então uma tabela sepa¬ 
rada de thread é necessária, com uma entrada por thread. 
Entre os itens por thread , estão o contador de programa, os 
registradores e o estado. 0 contador de programa é neces¬ 
sário porque os threads, como os processos, podem ser sus¬ 
pensos e retomados. Os registradores são necessários por¬ 
que quando os threads são suspensos, seus registradores 
devem ser salvos. Por fim, os threads, como os processos, 
podem estar no estado em execução, pronto ou bloquea¬ 
do. 

Em alguns sistemas, o sistema operacional não está ci¬ 
ente dos threads. Em outras palavras, eles são gerenciados 
inteiramente no espaço do usuário. Quando um thread está 
para bloquear, por exemplo, ele escolhe e inicia seu suces¬ 
sor antes de parar. Vários pacotes de threads no nível do 
usuário são de uso comum, incluindo os pacotes POSIX P- 
threads e Mach C -threads. 

Em outros sistemas, o sistema operacional está ciente 
da existência de múltiplos threads por processo, então, 
quando um thread bloqueia, o sistema operacional esco¬ 
lhe o próximo a executar, seja do mesmo processo seja de 
um diferente. Para fazer o agendamento, o kernel deve ter 
uma tabela de threads que lista todos os threads no siste¬ 
ma, análoga à tabela de processos. 

Embora essas duas alternativas possam parecer equi¬ 
valentes, elas diferem consideravelmente em desempenho. 
A comutação de threads é muito mais rápida quando o 
gerenciamento de threads é feito no espaço do usuário do 
que quando uma chamada de kernel é necessária. Esse fato 
é um argumento forte para fazer o gerenciamento de thre¬ 
ads no espaço do usuário. Por outro lado, quando os thre¬ 


ads são gerenciados inteiramente no espaço do usuário e 
um thread bloqueia (p. ex., esperando uma E/S ou uma 
falha de página ser gerenciada), o kernel bloqueia o pro¬ 
cesso inteiro, uma vez que ele nem mesmo está ciente da 
existência de threads. Esse fato é um argumento forte para 
fazer o gerenciamento de threads no kernel. Como con¬ 
sequência, os dois sistemas estão em uso e tambe'm fo¬ 
ram propostos vários esquemas híbridos (Anderson et ai, 
1992). 

Independente de os threads serem gerenciados pelo ker¬ 
nel ou no espaço usuário, eles introduzem diversos proble¬ 
mas que deve ser resolvidos e que mudam o modelo de pro¬ 
gramação consideravelmente. Para começar considere os 
efeitos da chamada de sistema fork. Se o processo-pai ti¬ 
ver múltiplos threads, o filho também deve tê-los? Se não, 
o processo pode não funcionar adequadamente, uma vez 
que todos eles podem ser essenciais. 

Entretanto, se o processo-filho recebe tantos threads 
quanto o pai, o que acontece se um thread for bloqueado 
em uma chamada READ, digamos, do teclado? Dois threa¬ 
ds agora estão bloqueados no teclado? Quando uma linha 
é digitada, os dois threads obtêm uma cópia dela? Só o pai? 
Só o filho? 0 mesmo problema existe com conexões de rede 
abertas. 

Outra classe de problemas está relacionada com o fato 
de que os threads compartilham muitas estruturas de da¬ 
dos. 0 que acontece se um thread fecha um arquivo en¬ 
quanto outro ainda está lendo esse arquivo? Suponha que 
um thread perceba que há muito pouca memória e come¬ 
ce a alocar mais memória. Então, no meio do caminho, 
ocorre uma comutação de threads. e o novo thread tam¬ 
bém percebe que há pouca memória e também começa a 
alocar mais memória. A alocação acontece uma ou duas 
vezes? Em quase todos os sistemas que não foram projeta¬ 
dos com threads em mente, as bibliotecas (como o proce¬ 
dimento de alocação de memória) não são reentrantes e 
causarão uma falha se uma segunda chamada for feita 
enquanto a primeira ainda está ativa. 

Outro problema está relacionado com o informe de er¬ 
ros. No UNIX, após uma chamada de sistema, o status da 
chamada é colocado em uma variável global, ermo. O que 
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acontece se um threacl fizer uma chamada de sistema e, 
antes de ele ser capaz de ler errno, outro thread faz uma 
chamada de sistema, apagando o valor original? 

Depois, considere os sinais. Alguns sinais são logica¬ 
mente específicos ao thread, enquanto outros, não. Por 
exemplo, se um thread chama aiarm, faz sentido para o 
sinal resultante ir para o thread que fez a chamada. Quan¬ 
do o kernel está ciente dos threads, ele normalmente certi¬ 
fica-se de que o thread correto obteve o sinal. Quando o 
kernel não está ciente dos threads, de alguma maneira o 
pacote de threads deve monitorar os alarmes. Existe uma 
complicação adicional para threads no nível do usuário 
quando (como no UNIX) um processo só pode ter um alar¬ 
me pendente por vez e vários threads chamam alarm inde¬ 
pendentemente. 

Outros sinais, como interrupção de teclado, não são 
específicos ao thread. Quem deve capturá-los? Um thread 
específico? Todos os threads ? Um thread recentemente cri¬ 
ado? Todas essas soluções têm problemas. Além disso, o que 
acontece se um thread altera os manipuladores de sinal 
sem informar aos outros threadsl 

Um último problema introduzido por threads é o ge¬ 
renciamento de pilha. Em muitos sistemas, quando ocorre 
estouro de pilha, o kernel apenas fornece mais pilha, auto¬ 
maticamente. Quando um processo tem múltiplos threa¬ 
ds, ele também deve ter múltiplas pilhas. Se o kernel não 
estiver ciente de todas essas pilhas, ele não poderá aumen¬ 
tá-las automaticamente no caso de falha de pilha. De fato, 
ele nem mesmo pode saber que uma falha de memória 
está relacionada com o crescimento da pilha. 

Esses problemas certamente não são insuperáveis, mas 
eles mostram que apenas a introdução de threads em um 
sistema existente sem um reprojeto relativamente substan¬ 
cial do sistema não funcionará absolutamente. A semânti¬ 
ca das chamadas de sistema tem de ser redefinida, e as bi¬ 
bliotecas devem ser reescritas, no mínimo. E todas essas 
coisas devem ser feitas de tal maneira que permaneçam 
retroativamente compatíveis com programas existentes para 
o caso limitante de um processo com um só thread. Para 
informações adicionais sobre threads, consulte Hauser e 
colaboradores, 1993, e Marsh e colaboradores, 1991- 

2.2 COMUNICAÇÃO INTERPROCESSO 

Os processos freqüentemente precisam comunicar-se 
com outros processos. Porexemplo, em um pipeline do shell, 
a saída do primeiro processo deve ser passada para o se¬ 
gundo processo e assim por diante ao longo da linha. Por¬ 
tanto, há uma necessidade de comunicação entre proces¬ 
sos, preferivelmente de uma maneira bem-estruturada que 
não utilize interrupções. Nas seções a seguir, examinare¬ 
mos algumas questões relacionadas com essa Comunica¬ 
ção InterProcessos ou CIP. 

Bem resumidamente, há três questões aqui. A primeira 
foi aludida acima: como um processo pode passar as infor¬ 
mações para outro. A segunda tem a ver com certificar-se 


de que dois ou mais processos não interfiram um com ou¬ 
tro quando envolvidos em atividades críticas (suponha dois 
processos tentando agarrar os últimos 100K de memória). 
A terceira diz respeito ao seqüenciamento adequado quan¬ 
do estão presentes dependências: se o processo ri produz 
dados e o processo B os imprime, B tem de esperar até que 
A tenha produzido alguns dados antes de começar a impri¬ 
mir. Examinaremos essas três questões agora, começando 
já na seção seguinte. 

2.2.1 Condições de Corrida 

Em alguns sistemas operacionais, processos que estão 
trabalhando juntos podem compartilhar algum armaze¬ 
namento comum que cada um pode ler e gravar. 0 arma¬ 
zenamento compartilhado pode estar na memória princi¬ 
pal ou pode ser um arquivo compartilhado; a localização 
da memória compartilhada não muda a natureza da co¬ 
municação ou os problemas que surgem. Para ver como a 
comunicação interprocesso funciona na prática, conside¬ 
raremos um exemplo simples mas comum, um spooler de 
impressão. Quando um processo quer imprimir um arqui¬ 
vo, ele insere o nome de arquivo em um diretório de spo¬ 
oler especial. Outro processo, o servidor de impressão, 
verifica periodicamente se há qualquer arquivo a ser im¬ 
presso e, se houver, ele os imprime e, então, remove seus 
nomes do diretório. 

Imagine que nosso diretório d espooler tenha um grande 
(potencialmente infinito) número de entradas, numera¬ 
das como 0, 1,2, ..., cada uma capaz de armazenar um 
nome de arquivo. Imagine também que haja duas variá¬ 
veis compartilhadas: out, que aponta para o próximo ar¬ 
quivo a ser impresso, e in, que aponta para a próxima en¬ 
trada livre no diretório. Essas duas variáveis podem ser 
mantidas em um arquivo de duas palavras disponível para 
todos os processos. Em um certo instante, as entradas 0 a 3 
estão vazias (os arquivos já foram impressos) e as entradas 
4 a 6 estão cheias (com os nomes colocados na fila de im¬ 
pressão). Mais ou menos simultaneamente, os processos ri 
e B decidem que querem colocar um arquivo na fila de 
impressão. Essa situação é mostrada na Figura 2-7. 

Em situações onde a lei de Murphy* é aplicável, pode 
acontecer o seguinte. O processori lê in e armazena o va¬ 
lor, 7, em uma variável local chamada next_Jree_slot. Só 
que, então, ocorre uma interrupção de relógio, e a CPU 
decide que o processo ri executou por tempo suficiente, e, 
então, alterna para o processo B. O processo B também lê 
in, e também recebe um 7, então, ele armazena o nome de 
seu arquivo no slot 7 e atualiza in para que ele seja 8. En¬ 
tão, ele segue adiante e faz outras coisas. 

Por fim, o processori executa novamente, iniciando do 
lugar em que parou. Ele examina next_Jree_slot, encon¬ 
tra um 7 aí e escreve seu nome de arquivo na entrada 7, 
apagando o nome que o processo B acabou de colocar ali. 


"N. de R. Se algo pode dar errado, dará. 
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Figura 2-7 Dois processos querem acessar a memória compartilhada ao mesmo tempo. 


Então, ele calcula next Jree_slot + 1, o que dá 8, e define 
in como 8. 0 diretório do spooler está agora internamente 
consistente, portanto, o servidor de impressão não notará 
nada de errado, mas o processo B nunca realizará qual¬ 
quer saída. Situações como essa, em que dois ou mais pro¬ 
cessos estão lendo ou gravando alguns dados compartilha¬ 
dos, e o resultado final depende de quem executa precisa¬ 
mente quando, são chamadas condições de corrida (race 
conditions). Depurar programas contendo condições de 
corrida não é nada divertido. Os resultados da maioria dos 
testes são bons, mas, de vez em quando, acontece algo es¬ 
tranho e inexplicável. 

2.2.2 Seções Críticas 

Como evitamos as condições de corrida? A chave para 
prevenir problemas aqui e em muitas outras situações en¬ 
volvendo memória compartilhada, arquivos compartilha¬ 
dos e tudo mais compartilhado é encontrar alguma ma¬ 
neira de proibir que mais de um processo leia e grave os 
dados compartilhados ao mesmo tempo. Dito em outras 
palavras, precisamos de uma exclusão mútua — uma 
maneira de certificarmo-nos de que se um processo está 
utilizando um arquivo ou variável compartilhado, os ou¬ 
tros processos serão impedidos de fazer a mesma coisa. A 
dificuldade acima ocorria porque o processo B começava 
utilizando uma das variáveis compartilhadas antes de o 
processo/l ter acabado de trabalhar com ela. A escolha das 
operações primitivas apropriadas para obter a exclusão 
mútua é uma questão de projeto importante em qualquer 
sistema operacional e um assunto que examinaremos de¬ 
talhadamente nas seções a seguir. 

0 problema de evitar as condições de corrida também 
pode ser formulado de uma maneira abstrata. Parte do tem¬ 
po, um processo fica ocupado fazendo computações inter¬ 
nas e outras coisas que não conduzem a condições de cor¬ 
rida. Entretanto, às vezes, um processo pode estar acessan¬ 
do memória compartilhada ou arquivos compartilhados, 


ou fazer outras coisas críticas que podem levar à condições 
de corrida. Essa parte do programa em que a memória com¬ 
partilhada é acessada é chamada região crítica ou seção 
crítica. Se pudéssemos organizar os problemas de tal modo 
que nenhum dos dois processos jamais estivesse em suas 
regiões críticas ao mesmo tempo, poderíamos evitar as con¬ 
dições de corrida. 

Embora esse requisito evite as condições de corrida, isso 
não é suficiente para ter processos paralelos que cooperam 
correta e efetivamente, utilizando dados compartilhados. 
Precisamos sustentar quatro condições para ter uma boa 
solução: 

1. Nenhum dos dois processos pode estar simultane¬ 
amente dentro de suas regiões críticas. 

2. Nenhuma suposição pode ser feita sobre as veloci¬ 
dades ou sobre o número de CPUs. 

3. Nenhum processo que executa fora de sua região 
crítica pode bloquear outro processo. 

4. Nenhum processo deve ter de esperar eternamente 
para entrar em sua região crítica. 

2.2.3 Exclusão Mútua com Espera 
Ativa 

Nesta seção, examinaremos várias propostas para obter 
exclusão mútua, de modo que enquanto um processo está 
ocupado atualizando a memória compartilhada em sua 
região crítica, nenhum outro processo entrará em sua re¬ 
gião crítica para causar problemas. 

Desativando as Interrupções 

A solução mais simples é fazer cada processo desativar 
todas as interrupções imediatamente depois de ele entrar 
em sua região crítica e reativá-las imediatamente depois 
de ele sair dela. Com as interrupções desativadas, nenhu¬ 
ma interrupção de relógio pode ocorrer. A CPU só alterna 
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de um processo para outro como resultado de interrupções 
de relógio ou de outras interrupções; no final das contas, 
com as interrupções desligadas a CPU não alternará de um 
processo para outro. Assim, uma vez que um processo de¬ 
sativou as interrupções, ele pode examinar e atualizar a 
memória compartilhada sem medo de que qualquer outro 
processo intervirá. 

Essa abordagem é geralmente pouco atraente porque 
não é aconselhável dar o poder de desativar interrupções a 
processos de usuário. Suponha que um deles faça isso e 
nunca mais as ative novamente? Isso poderia ser o fim do 
sistema. Além disso, se o sistema é multiprocessado, com 
duas ou mais CPUs, desativar interrupções afeta só a CPU 
que executou a instrução de desativamento. As outras con¬ 
tinuarão executando e podem acessar a memória compar¬ 
tilhada. 

Por outro lado, freqüentemente é conveniente para o 
próprio kemel desativar interrupções pelo tempo de algu¬ 
mas instruções enquanto ele está atualizando variáveis ou 
listas. Se uma interrupção ocorreu enquanto a lista de pro¬ 
cessos prontos, por exemplo, estava em um estado incon¬ 
sistente, poderiam ocorrer condições de corrida. A conclu¬ 
são é: desativar interrupções é freqüentemente uma técni¬ 
ca útil dentro do sistema operacional em si, mas não é apro¬ 
priada como um mecanismo geral de exclusão mútua para 
processos de usuário. 

Variáveis de Bloqueio 

Como uma segunda tentativa, vamos procurar uma 
solução de software. Considere ter uma variável única com¬ 
partilhada (bloqueio) inicialmente como 0. Quando um 
processo quer entrar em sua região crítica, ele primeiro 
testa o bloqueio. Se o bloqueio for 0, o processo o define 
como 1 e entra na região crítica. Se o bloqueio já for 1, o 
processo apenas espera até ele tornar-se 0. Assim, 0 signifi¬ 
ca que nenhum processo está em sua região crítica e 1 sig¬ 
nifica que algum processo está em sua região crítica. 

Infelizmente, essa idéia contém exatamente o mesmo 
defeito fatal que vimos no diretório do spooler. Suponha 
que o processo leia o bloqueio e veja que ele é 0. Antes de 
poder definir o bloqueio como 1, outro processo é agenda¬ 
do, executa e define o bloqueio como 1. Quando o primei¬ 
ro processo executa novamente, ele também definirá o blo¬ 
queio como 1, e os dois processos estarão em suas regiões 
críticas ao mesmo tempo. 


while (TRUE) { 
while (turn != 0) /* espera */; 
critical_region(); 
turn = 1; 

noncritical_region(); 

} 


Agora você pode pensar que poderíamos evitar esse pro¬ 
blema lendo primeiro o valor de bloqueio e, então, verifi- 
cando-o novamente, imediatamente antes de armazenar 
nele, mas isso na verdade não ajuda. A condição de corrida 
agora ocorre se o segundo processo modifica o bloqueio 
imediatamente depois de o primeiro processo acabar de 
fazer sua segunda verificação. 

Alternância Estrita 

Uma terceira abordagem para o problema de exclusão 
mútua é mostrada na Figura 2-8. Esse fragmento de pro¬ 
grama, como quase todos os outros neste livro, é escrito em 
C. A linguagem C foi escolhida aqui, porque os sistemas 
operacionais reais comumente são escritos em C (ou oca¬ 
sionalmente em C++), mas quase nunca em linguagens 
como Modula 2 ou Pascal. 

Na Figura 2-8, a variável de número inteiro turn, ini¬ 
cialmente 0, monitora aquele de quem é a vez (turn) de 
entrar na região crítica e examinar ou atualizar a memó¬ 
ria compartilhada. Inicialmente, o processo 0 inspeciona 
turn. descobre que ele é 0 e entra na sua região crítica. O 
processo 1 também descobre que ele é 0 e. portanto, entra 
em um laço estrito testando turn continuamente para ver 
quando ele se torna 1. Testar continuamente uma variável 
até que algum valor apareça é chamado espera ativa. Nor¬ 
malmente deve ser evitado, uma vez que desperdiça tempo 
de CPU. Só quando há uma expectativa razoável de que a 
espera seja curta é que a espera ativa é utilizada. 

Quando o processo 0 sai da região crítica, ele define 
turn como 1, permitindo que o processo 1 entre em sua 
região crítica. Suponha que o processo 1 termine de traba¬ 
lhar em sua região crítica rapidamente, então, ambos os 
processos estão em suas regiões não-críticas, com turn con¬ 
figurado como 0. Agora o processo 0 executa seu laço in¬ 
teiro rapidamente, voltando para sua região não-crítica com 
turn configurado como 1. Nesse ponto, o processo 1 acaba 
de trabalhar na sua região não-crítica e volta ao topo do 
seu laço. Infelizmente, ele não tem permissão para entrar 
na sua região crítica agora, porque turn está configurado 
como 1 e o processo 1 está ocupado com sua região não- 
crítica. Colocado de maneira diferente, a utilização de tur¬ 
nos (turn) não é uma boa idéia quando um dos processos 
é muito mais lento do que o outro. 

Essa situação viola a condição 3 estabelecida anterior¬ 
mente: o processo 1 está sendo bloqueado por um processo 


while (TRUE) { 
while (turn != 1 ) /* espera */; 
critical_region(); 
turn = 0; 

noncritical_region(); 

} 


(a) 


(b) 


Figura 2-8 Uma solução proposta para o problema da região crítica. 
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que não está em sua região crítica. Voltando ao diretório 
de spooler já discutido, se agora associássemos a região crí¬ 
tica com leitura e com gravação do diretório de spooler. o 
processo 0 não teria permissão para imprimir outro arqui¬ 
vo porque o processo 1 estaria fazendo outra coisa. 

De fato, essa solução requer que os dois processos alter¬ 
nem estritamente sua entrada nas suas regiões críticas, por 
exemplo, em arquivos de spool. Nenhum deles teria per¬ 
missão para fazer dois spools em fila. Embora esse algorit¬ 
mo realmente evite todas as condições de corridas, na rea¬ 
lidade, ele não é um candidato sério como uma solução 
porque viola a condição 3. 

A Solução de Peterson 

Combinando a idéia de turnos com a idéia de variáveis 
de bloqueio e variáveis de aviso, o matemático holandês T. 
Dekker foi o primeiro a projetar uma solução de software 
para o problema da exclusão mútua que não requer alter¬ 
nância estrita. Para uma discussão sobre o algoritmo de 
Dekker, consulte (Dijkstra, 1965). 

Em 1981, G.L. Peterson descobriu um modo muito mais 
simples de obter a exclusão mútua, tornando obsoleta as¬ 
sim a solução de Dekker. 0 algoritmo de Peterson é mos¬ 
trado na Figura 2-9- Esse algoritmo consiste em dois pro¬ 
cedimentos escritos em ANSI C, o que significa que protóti¬ 
pos de função devem ser fornecidos para todas as funções 
definidas e utilizadas. Entretanto, para poupar espaço, não 
mostraremos os protótipos neste exemplo nem nos subse- 
qüentes. 

Antes de utilizar as variáveis compartilhadas (i. e., an¬ 
tes de entrar em sua região crítica), cada processo chama 
enter_region com seu próprio número de processo, 0 ou 1, 
como parâmetro. Essa chamada causará espera, se neces¬ 
sário, até que seja seguro entrar. Depois que terminou de 


trabalhar com as variáveis compartilhadas, o processo cha¬ 
ma leave_region para indicar que terminou e permitir que 
o outro processo entre, se ele, então, quiser. 

Deixe-nos ver como essa solução funciona. Inicialmente 
nenhum processo está em sua região crítica. Agora o pro¬ 
cesso 0 chama enter_region. Ele indica seu interesse, con¬ 
figurando seu elemento da matriz e configura turn como 
0. Como o processo 1 não está interessado, enter_jegion 
retorna imediatamente. Se o processo 1 agora chamar 
enter jregion, ele ficará parado aí até que interested[0] 
torne-se FALSE, evento que só acontece quando o processo 
0 chama leave jregion para sair da região crítica. 

Agora, considere o caso em que os dois processos cha¬ 
mam enter j-egion quase simultaneamente. Ambos arma¬ 
zenarão seu número de processo em turn. Qualquer que 
seja o armazenamento feito por último, é este que conta; o 
primeiro é perdido. Suponha que o processo 1 armazene 
por último, assim turn é 1. Quando ambos os processos 
chegam na declaração while, o processo 0 a executa zero 
vezes e entra em sua região crítica. O processo 1 entra em 
laço e não entra em sua região crítica. 

A Instrução TSL 

Agora vejamos uma proposta que requer uma pequena 
ajuda do hardware. Muitos computadores, especialmente 
aqueles projetado com múltiplos processadores em mente, 
têm uma instrução TEST and SET LOCK (TSL — testa e con¬ 
figura o bloqueio) que funciona como segue. Ela lê o con¬ 
teúdo da palavra de memória em um registrador e, então, 
armazena um valor diferente de zero nesse endereço de 
memória. As operações de leitura e de armazenamento da 
palavra são garantidas como sendo indivisíveis — nenhum 
outro processador pode acessar a palavra de memória até 
que a instrução tenha acabado. A CPU que executa a ins- 


#define FALSE 0 

#defineTRUE 1 

#define N 2 

int turn; 

int interested[N]; 

void enter_region(int process); 

{ 

int other; 

other = 1 - process; 
interested[process] = TRUE; 
turn = process; 

while (turn == process && interested[other] == TRUE) 

} 

void leave region(int process) 

{ 

interested [process] = FALSE; 

} 


/* número de processos */ 

/* de quem é a vez (turn)? */ 

/* todo os valores inicialmente 0 (FALSE) */ 

/* o process é 0 ou 1 */ 

/* número dos outros processos */ 

/* o oposto do processo */ 

/* mostra que você está interessado */ 

/* define o sinalizador */ 

/* declaração nula */; 


/* processo: quem está saindo*/ 
/* indica saída da região crítica */ 


Figura 2-9 A solução de Peterson para obter exclusão mútua. 
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trução tsl bloqueia o barramento de memória, proibindo 
outras CPUs de acessar a memória ate' que ela tenha termi¬ 
nado. 

Para utilizar a instrução tsl, utilizaremos uma variá¬ 
vel compartilhada, lock , para coordenar o acesso à memó¬ 
ria compartilhada. Quando lock é 0. qualquer processo pode 
configurá-la como 1 utilizando a instrução TSL e, então, 
ler ou gravar a memória compartilhada. Quando termina, 
o processo configura lock de volta para 0 utilizando uma 
instrução MOVE comum. 

Como essa instrução pode ser utilizada para prevenir 
que dois processos entrem simultaneamente em suas regi¬ 
ões críticas? A solução é dada na Figura 2-10. Essa figura 
mostra uma sub-rotina de quatro instruções em uma fictí¬ 
cia (mas típica) linguagem assembly. A primeira instru¬ 
ção copia o valor antigo de lock para o registrador e, então, 
configura lock como 1. Então, o valor antigo é comparado 
com 0. Se for diferente de zero, o bloqueio já foi definido e, 
então, o programa volta para o começo e testa novamente. 
Cedo ou tarde, ele se tornará 0 (quando o processo atual¬ 
mente em sua região crítica terminar de trabalhar nela) e 
a sub-rotina retorna com o bloqueio configurado. Limpar 
o bloqueio é simples. O programa simplesmente armazena 
um 0 em lock. Nenhuma instrução especial e' necessária. 

Uma solução para o problema da região crítica agora é 
simples. Antes de entrar em sua região crítica, um processo 
chama enter jregion, que faz a espera ativa até que o blo¬ 
queio esteja livre; então, ele adquire o bloqueio e retorna. 
Depois da região crítica, o processo chama leavejregion, 
que armazena um 0 em lock. Como ocorre em todas as 
soluções baseadas em regiões críticas, os processos devem 
chamar enter jregion e leave_region nos momentos cer¬ 
tos para o método funcionar. Se um processo trapacear, a 
exclusão mútua falhará. 

2.2.4 Sleep e Wakeup 

Tanto a solução de Peterson como a solução que utiliza 
TSL são corretas, mas ambas têm o defeito de necessitar da 
espera ativa. Essencialmente, o que essas soluções fazem é 
isto: quando um processo quer entrar em sua região críti¬ 
ca, ele verifica se a entrada é permitida. Se não for, o pro¬ 
cesso apenas espera em um laço estrito até que seja. 

Essa abordagem não apenas desperdiça tempo de CPU 
como também pode ter efeitos inesperados. Considere um 


computador com dois processos, //, com alta prioridade, e 
L, com baixa prioridade. As regras de agendamento são tais 
que H é executado sempre que está em estado pronto. Em 
um certo momento, com L em sua região crítica, H torna- 
se pronto para executar (p. ex., uma operação de E/S com- 
pleta-se). H agora começa a espera ativa, mas comoZ nun¬ 
ca é agendado quando H está executando, L nunca tem a 
chance de sair da sua região crítica, então H fica em um 
laço eterno. Essa situação é, às vezes, referida como pro¬ 
blema da inversão de prioridade. 

Agora vejamos algumas primitivas de comunicação 
interprocesso que bloqueiam em vez de desperdiçar tempo 
de CPU quando a eles não é permitido entrar em suas regi¬ 
ões críticas. Uma das mais simples é o par sleep e wakeup. 
SLEEP é uma chamada de sistema que causa o bloqueio do 
processo que fez a chamada, isto é, ele é suspenso até que 
outro processo o acorde. A chamada wakeup tem um parâ¬ 
metro, o processo a ser acordado. Alternativamente, SLEEP 
e WAKEUP têm um parâmetro, um endereço de memória 
utilizado para coincidir os SI.eeps com os wakeups. 

O Problema dos Produtores e 
Consum idores 

Como um exemplo de como essas primitivas podem ser 
utilizadas, consideremos o problema dos produtores e 
dos consumidores (também conhecido como problema 
do buffer associado). Dois processos compartilham um 
buffer de tamanho fixo. Um deles, o produtor, coloca as 
informações em um buffer e o outro, o consumidor, pega- 
as. (Também é possível generalizar o problema para ter m 
produtores e n consumidores, mas consideraremos apenas 
o caso de um produtor e de um consumidor porque essa 
suposição simplifica as soluções). 

O problema surge quando o produtor quer colocar um 
novo item no buffer, mas este último já está cheio. A solu¬ 
ção é o produtor ir dormir para ser acordado quando o con¬ 
sumidor remover um ou mais itens. De maneira semelhan¬ 
te, se o consumidor quiser remover um item do buffer e ver 
que o buffer está vazio, ele adormecerá até que o produtor 
coloque algo no buffer e o acorde. 

Essa abordagem parece suficientemente simples, mas 
conduz ao mesmo tipo de condição de corrida que vimos 
anteriormente com o diretório de spooler. Para monitorar 
o número de itens no buffer, precisaremos de uma variá- 


enter_region: 

tsl register.lock | copia lock para o registrador e o configura como 1 

cmp register,#0 j lock era zero? 

jne enter region j se não era zero, o bloqueio estava configurado, então inicia um laço 

ret i retorna para aquele que fez a chamada; entrada na região crítica 


leave_region: 

move lock,#0 | armazena um 0 no bloqueio (lock) 

ret i retorna para aquele que fez a chamada 


Figura 2-10 Configurando e limpando bloqueios utilizando TSL. 
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vel, count. Se o número máximo de itens que o buffer pode 
armazenar for A', o código do produtor primeiro testará se 
count éN. Se for. o produtor adormecerá; se não, o produ¬ 
tor adicionará um item e aumentará count. 

O código para o consumidor é semelhante: primeiro 
testa count para ver se é 0. Se for, adormecerá; se for dife¬ 
rente de zero, removerá um item e diminuirá o contador. 
Cada um dos processos também testa para ver se o outro 
deveria estar dormindo e, se não, ele o acorda. Os códigos 
para o produtor e para o consumidor são mostrados na Fi¬ 
gura 2-11. 

Para expressar chamadas de sistema como SI.eep e 
wakeüp em C, nós as mostraremos como chamadas para 
rotinas de biblioteca. Elas não são parte da biblioteca C 
padrão, mas presumivelmente estariam disponíveis em 
qualquer sistema que realmente tivesse essas chamadas de 
sistema. Os procedimentos enter Jtem e remove Jtem, que 
não são mostrados, gerenciam o trabalho de colocar itens 
no buffer e remover itens do mesmo. 

Agora voltemos à condição de corrida. Ela pode ocorrer 
porque o acesso a count é irrestrito. A seguinte situação 
possivelmente poderia ocorrer. O buffer está vazio e o con¬ 
sumidor terminou de ler count para ver se ele é 0. Nesse 
instante, o agendador decide parar de executar o consumi¬ 
dor temporariamente e começar a executar o produtor. O 
produtor insere um item no buffer, aumentando count e 
avisa que ele agora é 1. Deduzindo que count era apenas 0, 
e assim o consumidor deveria estar dormindo, o produtor 
chama wakeup para acordar o consumidor. 

Infelizmente o consumidor ainda não está logicamen¬ 
te adormecido, então, o sinal para acordar é perdido. Quan¬ 
do o consumidor executar da próxima vez, ele testará o 

#define N 100 
int count = 0; 

void producer(void) 

{ 

while (TRUE) { 

produce_item(); 

if (count== N) sleepO; 

enter_ item(); 

count = count + 1; 

if (count == 1) wakeup(consumer); 

} 

} 


void consumer(void) 

{ 

while (TRUE) { 

if (count == 0) sleepO; 
removeJtemQ; 
count = count - 1; 

if (count == N - 1) wakenp (producer); 
consume_item(); 

} 

} 


valor de count anteriormente lido, verificará que ele é 0, e, 
então, irá dormir. Cedo ou tarde, o produtor encherá o bu¬ 
ffer e também irá dormir. Ambos dormirão eternamente. 

A essência do problema aqui é que um sinal para acor¬ 
dar enviado para um processo que não está dormindo (ain¬ 
da) é perdido. Se ele não fosse perdido, tudo funcionaria. 
Uma rápida correção é modificar as regras, adicionando 
um bit de espera por despertar ao quadro geral. Quan¬ 
do um sinal para acordar é enviado para um processo que 
ainda está acordado, esse bit é ativado. Mais tarde, quando 
o processo tenta ir dormir, se o bit de espera por despertar 
estiver ativado, ele será desativado, mas o processo perma¬ 
necerá acordado. O bit de espera por despertar é um banco 
para sinais de acordar. 

Embora o bit de espera por despertar “salve a pátria” 
nesse exemplo simples, é fácil construir exemplos com três 
ou mais processos em que um bit de espera por despertar é 
insuficiente. Poderíamos fazer outro remendo e adicionar 
um segundo bit de espera por despertar ou talvez 8 ou 32 
deles, mas, em princípio, o problema ainda está aí. 

2.2.5 Semáforos 

Esta era a situação em 1965, quando E. W. Dijkstra 
(1965) sugeriu utilizar uma variável inteira para contar 0 
número de wakeups salvos para uso futuro. Em sua pro¬ 
posta, um novo tipo de variável chamado semáforo foi 
introduzido. Um semáforo poderia ter 0 valor 0, indicando 
que nenhum wakeup foi salvo ou algum valor positivo se 
um ou mais wakeups estivessem pendentes. 

Dijkstra propôs ter duas operações down e up (genera¬ 
lizações de sleep e WAKEUP, respectivamente). A operação 


I* número de entradas no buffer */ 
/* número de itens no buffer */ 


/* repete eternamente */ 

/* gera o item seguinte */ 

/* se o buffer estiver cheio, vai dormir */ 

/* coloca item no buffer */ 

/* aumenta a contagem de items no buffer */ 
/* o buffer estava vazio? */ 


/* repete eternamente */ 

/* se o buffer estiver vazio, vai dormir */ 

/* remove item do buffer */ 

/* diminiu a contagem de itens no buffer */ 
/* o buffer estava cheio? */ 

/* imprime 0 item */ 


Figura 2-11 O problema dos produtores e consumidores com uma condição de corrida fatal. 
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DOWN em um semáforo verifica se o valor é maior que 0. Se 
for, ele diminui o valor (i. e., utiliza um wakeup armaze¬ 
nado) e simplesmente continua. Se o valor for 0, o proces¬ 
so é colocado para dormir sem completar o DOWN, por en¬ 
quanto. Verificar o valor, alterá-lo e, possivelmente, ir dor¬ 
mir é tudo feito como uma única e indivisível ação atômi¬ 
ca. É garantido que uma vez que uma operação de semá¬ 
foro iniciou, nenhum outro processo acesse o semáforo ate' 
que a operação tenha-se se completado ou tenha sido blo¬ 
queada. Essa atomicidade é absolutamente essencial para 
resolver problemas de sincronização e para evitar condi¬ 
ções de corrida. 

A operação UP incrementa o valor do semáforo endere¬ 
çado. Se um ou mais processos estavam dormindo nesse 
semáforo, incapazes de completar uma operação DOWN 
anterior, um deles e' escolhido pelo sistema (p. ex., aleato¬ 
riamente) e autorizado a completar seu doto. Assim, de¬ 
pois de um UP em um semáforo com processos adormeci¬ 
dos nele, o semáforo ainda será 0, mas haverá um processo 
a menos dormindo nele. A operação de incrementar o se¬ 
máforo e de acordar um processo também é indivisível. Ne¬ 
nhum processo bloqueia, utilizando um UP, assim como 


nenhum processo bloqueia, fazendo um wakkup no mode¬ 
lo anterior. 

A propósito do paper original de Dijkstra, ele utilizou os 
nomes P e V em vez de DOTO e UP, respectivamente, mas 
como aqueles não têm nenhum importância mnemónica 
para as pessoas que não falam holandês (e importância só 
marginal para aqueles que falam) utilizaremos os termos 
DOWN e UP no lugar deles. Esses foram introduzidos pela 
primeira vez no Algol 68. 

Resolvendo o Problema dos Produtores e 
dos Consumidores Utilizando Semáforos 

Os semáforos resolvem o problema do wakeup perdido 
como mostrado na Figura 2-12. É essencial que eles sejam 
implementados de uma maneira indivisível. A maneira 
normal é implementar UP e DOWN como chamadas de sis¬ 
tema com o sistema operacional brevemente desativando 
todas as interrupções, enquanto está testando o semáforo, 
atualizando-o e colocando o processo para dormir, se ne¬ 
cessário. Como todas essas ações precisam de apenas algu¬ 
mas instruções, não há nenhum prejuízo em desativar as 


#defineN100 /’ 

typedef int semaphore; /’ 

semaphore mutex = 1; /’ 

semaphore empty = N; /’ 

semaphore full = 0; /’ 


void producer(void) 

{ 

int item; 


while (TRUE) { f 

produce_item(&item); /’ 

down(&empty); /’ 

down(&mutex); /’ 

enter Jtem (item); /’ 

up(&mutex); /’ 

up(&full); /’ 


} 

} 


número de entradas no buffer */ 
semáforos são um tipo especial de int */ 
controle de acesso à região crítica */ 
conta as entradas livres do buffer */ 
conta as entradas utiizadas do buffer */ 


TRUE é a constante 1 */ 

gera algo para colocar no buffer */ 

diminui a contagem de entradas livres */ 

entra na região crítica */ 

coloca um novo item no buffer */ 

sai da região crítica */ 

aumenta a contagem de entradas utilizadas */ 


void consumer(void) 

{ 

int item; 


while (TRUE) { /* 

down (&full); /* 

down(&mutex); /* 

removeJtem(&item); /* 

up(&mutex); /* 

up(&empty); /* 

consumejtem(item); /* 

} 

} 


laço infinito */ 

diminui a contagem de entradas utilizadas */ 

entra na região crítica */ 

remove item do buffer */ 

sai de região crítica */ 

aumenta a contagem de entradas livres 

faz alguma coisa com o item */ 


Figura 2-12 0 problema dos produtores e dos consumidores utilizando semáforos. 
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interrupções. Se múltiplas CPUs estiverem sendo utiliza¬ 
das, cada semáforo deve ser protegido por uma variável de 
bloqueio com a instrução de TSt. utilizada para certificar 
que só uma CPU por vez examine o semáforo. Certifique- 
se de que você entendeu que utilizar TSt. para evitar que 
várias CPUs acessem o semáforo ao mesmo tempo é bem 
diferente da espera ativa pelo produtor ou pelo consumi¬ 
dor, esperando o outro esvaziar ou encher o buffer. A ope¬ 
ração de semáforo só leva alguns microssegundos enquanto 
o produtor ou o consumidor podem demorar um tempo 
arbitrariamente longo. 

Essa solução utiliza três semáforos: um chamado full 
para contar o número de entradas que estão ocupadas, um 
chamado empty para contar o número de entradas que 
estão livres e um chamado mutex para assegurar que o 
produtor e o consumidor não acessem o buffer ao mesmo 
tempo. Inicialmente full é 0, empty é igual ao número de 
entradas no buffer e mutex também é 1. Os semáforos que 
são inicializados como 1 e utilizados por dois ou mais pro¬ 
cessos para assegurar que só um deles possa entrar em sua 
região crítica ao mesmo tempo são chamadas semáforos 
binários. Se cada processo faz um doto imediatamente 
antes de entrar em sua região crítica e um UP somente de¬ 
pois de sair dela, a exclusão mútua é garantida. 

Agora que temos uma boa primitiva de comunicação 
interprocesso à nossa disposição, voltemos a ver as seqüên- 
cia de interrupções da Figura 2-5. Em um sistema que uti¬ 
liza semáforos, a maneira natural de ocultar interrupções 
é ter um semáforo inicialmente configurado como 0, asso¬ 
ciado com cada dispositivo de E/S. Imediatamente depois 
de iniciar um dispositivo de E/S, o processo gerenciador 
faz um doto no semáforo associado, bloqueando, assim, 
de imediato. Quando chega a interrupção, o gerenciador 
de interrupções faz um UP no semáforo associado, o qual 
torna o processo relevante pronto para executar novamen¬ 
te. Nesse modelo, o passo 6 na Figura 2-5 consiste em fazer 
um UP no semáforo do dispositivo, de modo que no passo 
7, o agendador será capaz de executar o gerenciador de 
dispositivo. Naturalmente, se agora vários processos estão 
prontos, o agendador pode escolher executar um processo 
ainda mais importante em seguida. Veremos como o agen- 
damento é feito mais adiante neste capítulo. 

No exemplo da Figura 2-12, utilizamos os semáforos, 
na realidade, de duas maneiras diferentes. Essa diferença é 
suficientemente importante para merecer ser explicitada. 
0 semáforo mutex é utilizado para exclusão mútua. Ele é 
projetado para garantir que só um processo por vez estará 
lendo ou gravando o buffer e as variáveis associadas. Essa 
exclusão mútua é requerida para evitar um caos. 

A outra utilização de semáforos é para sincronização. 
Os semáforos full e empty são necessários para garantir 
que certas seqüências de eventos ocorram ou não. Nesse 
caso, eles asseguram que o produtor pára de executar quan¬ 
do o buffer está cheio, e o consumidor pára de executar 
quando o buffer está vazio. Esse uso é diferente da exclu¬ 
são mútua. 


Embora a idéia dos semáforos exista há mais de um 
quarto de século, muitos estudiosos ainda estão fazendo 
pesquisa sobre sua utilização. Como um exemplo, consul¬ 
te (Tai e Carver, 1996). 

2.2.6 Monitores 

Com os semáforos, a comunicação interprocesso pare¬ 
ce fácil, certo? Esqueça. Examine de perto a ordem dos 
DOTOs antes de inserir ou de remover itens do buffer na 
Figura 2-12. Suponha que os dois DOTOs no código do pro¬ 
dutor foram invertidos na sua ordem, então, mutex foi di¬ 
minuído antes de empty em vez de depois dele. Se o buffer 
estivesse completamente cheio, o produtor bloquearia com 
mutex configurado como 0. Portanto, da próxima vez que 
o consumidor tentasse acessar o buffer, ele faria um DOTO 
em mutex, agora 0, e também bloquearia. Os dois proces¬ 
sos permaneceriam bloqueados eternamente e mais ne¬ 
nhum trabalho seria feito. Essa situação infeliz é chamada 
impasse ( deadlock ). Estudaremos impasses detalhada¬ 
mente no Capítulo 3- 

Esse problema é indicado para mostrar quanto cuida¬ 
do deve-se ter ao utilizar semáforos. Um erro sutil e tudo 
desaba. É como programação em linguagem assembly, só 
que pior, porque os erros são condições de corrida, de im¬ 
passes e de outras formas de comportamento imprevisíveis 
e irreproduzíveis. 

Para tornar mais fácil escrever programas corretos, 
Hoare (1974) e Brinch Hansen (1975) propuseram uma 
primitiva de sincronização de nível mais alto chamada 
monitor. Suas propostas diferiam ligeiramente como des¬ 
crito adiante. Um monitor é uma coleção de variáveis, de 
procedimentos e de estruturas de dados que são agrupados 
em um tipo especial de módulo ou de pacote. Os processos 
podem chamar os procedimentos em um monitor sempre 
que quiserem, mas eles não podem acessar diretamente as 
estruturas de dados internas do monitor a partir de proce¬ 
dimentos declarados fora do monitor. A Figura 2-13 ilustra 
úm monitor escrito em uma linguagem imaginária, se¬ 
melhante ao Pascal. 

Os monitores têm uma propriedade importante que os 
torna úteis para obter a exclusão mútua: só um processo 
pode._eslar ativo em um monitor em qualquer instante. Os 
monitores são uma construção de linguagem de progra¬ 
mação, de modo que o compilador sabe que eles são espe¬ 
ciais e pode gerenciar chamadas para procedimentos do 
monitor diferentemente de outras chamadas de procedi¬ 
mento. Em geral, quando um processo chama um proce¬ 
dimento do monitor, as primeiras poucas instruções do pro¬ 
cedimento verificarão se qualquer outro processo está atual¬ 
mente ativo dentro do monitor. Se estiver, o processo de 
chamada será suspenso até que o outro processo tenha dei¬ 
xado o monitor. Se nenhum outro processo estiver utili¬ 
zando o monitor, o processo de chamada pode entrar. 

Cabe ao compilador implementar a exclusão mútua em 
entradas de monitor, mas uma maneira comum é utilizar 
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monitor example 
integer /'; 
condition c; 

procedure producer[x}\ 


end; 


procedure consumeifx); 


end; 

end monitor; 


Figura 2-13 Um monitor. 


um semáforo binário. Como é o compilador, e não o pro¬ 
gramador, que está organizando a exclusão mútua, é mui¬ 
to menos provável que algo dê errado. De qualquer modo, 
a pessoa que escreve o monitor não precisa estar ciente de 
como o compilador organiza a exclusão mútua. É sufici¬ 
ente saber que transformando todas as regiões críticas em 
procedimentos de monitor, nunca dois processos executa¬ 
rão suas regiões críticas ao mesmo tempo. 

Embora os monitores ofereçam uma maneira fácil de 
obter exclusão mútua, como vimos anteriormente, isso não 
é suficiente. Também precisamos de uma maneira de blo¬ 
quear os processos quando eles não podem prosseguir. No 
problema do produtor-consumidor, é muito fácil colocar 
todos os testes para buffer cheio e para buffer vazio em pro¬ 
cedimentos de monitor, mas como o produtor deve bloque¬ 
ar quando encontra o buffer cheio? 

A solução reside na introdução de variáveis de condi¬ 
ção, junto com duas operações sobre elas, wait e SIGXAL. 
Quando um procedimento de monitor descobre que não 
pode continuar (p. ex., o produtor encontra o buffer cheio), 
ele faz um wait em alguma variável de condição, digamos, 
full. Essa ação causa o bloqueio do processo de chamada. 
Ela também permite que outro processo, que anteriormen¬ 
te tinha sido proibido de entrar no monitor, entre. 

Nesse outro processo, por exemplo, o consumidor pode 
acordar seu parceiro adormecido, fazendo um sigxal na 
variável de condição que seu parceiro está esperando. Para 
evitar ter dois processos ativos no monitor, ao mesmo tem¬ 
po, precisamos de uma regra informando o que acontece 
após um SIGXAL. Hoare propôs deixar o processo recente¬ 
mente acordado executar, suspendendo os outros. Brinch 
Hansen propôs refinar o problema requerendo que um pro¬ 
cesso que faz um SIGXAL saia do monitor imediatamente. 
Em outras palavras, uma declaração SIGXAL pode aparecer 
apenas como a declaração final em um procedimento de 
monitor. Utilizaremos a proposta de Brinch Hansen por ser 


conceitualmente mais simples e, também, mais fácil de 
implementar. Se um SIGXAL é feito em uma variável de con¬ 
dição em que vários processos estão esperando, só um de¬ 
les, determinado pelo agendador do sistema, é reanimado. 

As variáveis de condição não são contadores. Elas não 
acumulam sinais para uso futuro do modo como os semá¬ 
foros fazem. Assim, se uma variável de condição é sinaliza¬ 
da com ninguém esperando nela, o sinal é perdido. 0 WAIT 
deve vir antes do SIGNAL. Essa regra torna a implementa¬ 
ção muito mais simples. Na prática, não é um problema 
porque é fácil acompanhar o estado de cada processo com 
variáveis, se for necessário. Qualquer processo que pode 
fazer um SIGNAL verá que essa operação não é necessária 
examinando as variáveis. 

Um esqueleto do problema dos produtores e dos consu¬ 
midores com monitores é dado na Figura 2-14 em código- 
fonte parecido com o Pascal. 

Você pode estar pensando que as operações wait e sig- 
NAI. se parecem com as SLKKP e WAKKUP, que vimos anteri¬ 
ormente como conduzindo a condições de corrida fatais. 
De fato, elas são muito semelhantes, mas com uma dife¬ 
rença crucial: SLKKP e WAKKUP falhavam porque, enquanto 
um processo estava tentando ir dormir, o outro estava ten¬ 
tando acordá-lo. Com monitores, isso não pode acontecer. 
A exclusão mútua automática em procedimentos de moni¬ 
tor garante que se, digamos, o produtor dentro de um pro¬ 
cedimento de monitor descobre que o buffer está cheio, ele 
será capaz de completar a operação wait sem precisar preo- 
cupar-se com a possibilidade de o agendador poder alter¬ 
nar para o consumidor antes do wait completar-se. O con¬ 
sumidor não está nem mesmo será autorizado a entrar no 
monitor até wait terminar, e o produtor ser marcado como 
não mais executável. 

Tornando automática a exclusão mútua de regiões crí¬ 
ticas, os monitores tornaram a programação paralela muito 
menos sujeita a erros do que com semáforos. Mas eles ain- 
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monitor ProducerConsumer 
condition full, empty 
integer count, 

procedure enter, 
begin 

if count = A/then wait(Tu//); 
enterjtem ; 
count := count + 1; 
if count = 1 then signal (empty) 
end; 

procedure remove-, 
begin 

if count = 0 then wait (empty)] 
remove_item; 
count ;= count - 1; 
if count = W- 1 then signal (full) 
end; 

count := 0; 

end monitor; 

procedure producer, 
begin 

while frue do 
begin 

produce_item\ 

ProducerConsumer. enter 

end 

end; 

procedure consumer, 
begin 

while true do 
begin 

ProducerConsumer. remove\ 
consumejtem 

end 

end 

Figura 2-14 Um esboço do problema produtores e consumidores com monitores. Só 
um procedimento de monitor está ativo por vez. 0 buffer tem N entradas. 


da têm algumas desvantagens. Não é à-toa que a Figura 2- 
14 é escrita em um estranho Pascal em vez de em C, como 
são os outros exemplos neste livro. Como dissemos anteri¬ 
ormente, os monitores são um conceito de linguagem de 
programação. 0 compilador deve reconhecê-los e arranjar 
a exclusão mútua de algum modo. C, Pascal e a maioria 
das outras linguagens não têm monitores, então, não é ra¬ 
zoável esperar que seus compiladores implementem qual¬ 
quer regra de exclusão mútua. De fato, como o compilador 
poderia saber quais procedimentos estão em monitores e 
quais não estão? 

Essas mesmas linguagens também não têm semáforos, 
mas adicionar semáforos é fácil: tudo que você precisa fa¬ 
zer é adicionar à biblioteca duas curtas rotinas em código 
assembly para produzir as chamadas de sistema UP e DOTO. 
Os compiladores sequer precisam saber que elas existem. 
Naturalmente, os sistemas operacionais precisam saber dos 
semáforos, mas, se você tem pelo menos um sistema ope¬ 


racional baseado em semáforo, você ainda pode escrever 
os programas de usuário para ele em C ou C + + (ou mes¬ 
mo BASIC, se for masoquista o suficiente). Com monito¬ 
res, você precisa de uma linguagem que os tenha incorpo¬ 
rados. Algumas linguagens os têm, como a Concurrent 
Euclid (Holt, 1983), mas são raras. 

Outro problema com monitores e também com semá¬ 
foros é que eles foram projetados para resolver o problema 
de exclusão mútua em uma ou em mais CPUs que têm 
acesso a uma memória comum. Colocando os semáforos 
na memória compartilhada e protegendo-os com instru¬ 
ções TSL, podemos evitar as condições de corrida. Quando 
vamos para um sistema que consiste em múltiplas CPUs 
distribuídas, cada uma com sua própria memória privada, 
conectadas por uma rede local, essas primitivas tornam-se 
inaplicáveis. A conclusão é que semáforos são de muito 
baixo nível, e os monitores não são utilizáveis, exceto em 
algumas linguagens de programação. Além disso, nenhu- 
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ma das primitivas oferece troca de informações entre má¬ 
quinas. Algo mais é necessário. 

2.2.7 Passagem de Mensagem 

Esse algo mais é a passagem de mensagem. Esse 
método de comunicação interprocesso utiliza duas primi¬ 
tivas SEND e RECEIVE que, como os semáforos e, ao contrá¬ 
rio dos monitores, são chamadas de sistema em vez de cons¬ 
truções da linguagem. Como tal, eles podem ser facilmen¬ 
te colocados em procedimentos de biblioteca, como 

send(destination, &message); 

e 

receive(source, &message); 

A primeira chamada envia uma mensagem ( message) 
para um dado destino ( destination ) enquanto a segunda 
recebe uma mensagem de uma determinada origem (ou 
de qualquer, se o destinatário não se importar). Se nenhu¬ 
ma mensagem estiver disponível, ele poderia bloquear até 
uma chegar. Alternativamente, ele poderia retomar imedi¬ 
atamente com um código de erro. 

Questões de Projeto para Sistemas de 
Passagem de Mensagem 

Os sistemas de passagem de mensagem têm muitos pro¬ 
blemas desafiadores e questões de projeto que não surgem 
com os semáforos nem com os monitores, especialmente 
se os processos comunicantes estiverem em máquinas di¬ 
ferentes conectadas por uma rede. Por exemplo, as mensa¬ 
gens podem perder-se na rede. Para evitar perda de mensa¬ 
gens, o remetente e o destinatário podem concordar que 
logo que a mensagem for recebida, o destinatário enviará 
de volta uma mensagem especial de reconhecimento. Se 
o remetente não receber o reconhecimento dentro de um 
certo intervalo de tempo, ele retransmite a mensagem. 

Agora considere o que acontece se a mensagem em si é 
recebida corretamente, mas o reconhecimento perde-se. 0 
remetente retransmitirá a mensagem, de modo que o des¬ 
tinatário irá recebê-la duas vezes. É essencial que o desti¬ 
natário possa diferenciar entre uma nova mensagem e a 
retransmissão de uma antiga. Normalmente, esse proble¬ 
ma é resolvido colocando-se uma seqiiência de números 
consecutivos em cada mensagem original. Se o destinatá¬ 
rio receber uma mensagem contendo o mesmo número de 
seqüência que a mensagem anterior, ele sabe que a men¬ 
sagem é uma duplicata e que pode ser ignorada. 

Os sistemas de mensagem também têm de lidar com a 
pergunta de como os processos são nomeados, para que o 
processo especificado em uma chamada send ou receive 
não seja ambíguo. A autenticação também é uma ques¬ 
tão em sistemas de mensagem: como o cliente pode desco¬ 
brir que está comunicando-se com o verdadeiro servidor 
de arquivos e não com um impostor? 


Na outra extremidade do espectro, também há ques¬ 
tões de projeto que são importantes quando o remetente e 
o destinatário estão na mesma máquina. Uma delas é o 
desempenho. Copiar mensagens de um processo para ou¬ 
tro é sempre mais lento que fazer uma operação de semá¬ 
foro ou entrar em um monitor. Muito trabalho foi aplicado 
para fazer a passagem de mensagens eficiente. Cheriton 
(1984), por exemplo, sugeriu limitar o tamanho da men¬ 
sagem para um tamanho que caberá nos registradores da 
máquina, e, então, fazer a passagem da mensagem utili¬ 
zando os registradores. 

O Problema dos Produtores e dos 
Consumidores com a Passagem de 
Mensagem 

Agora vejamos como o problema dos produtores e dos 
consumidores pode ser resolvido com passagem de mensa¬ 
gem e de memória não-compartilhada. Uma solução é dada 
na Figura 2-15. Supomos que todas as mensagens são do 
mesmo tamanho e que as mensagens enviadas, mas ainda 
não-recebidas, são armazenadas automaticamente pelo sis¬ 
tema operacional. Nessa solução, um total de N mensa¬ 
gens é utilizado, análogo às N entradas em um buffer de 
memória compartilhada. O consumidor inicia enviando A' 
mensagens vazias para o produtor. Sempre que o produtor 
tem um item para dar ao consumidor, ele pega uma men¬ 
sagem vazia e envia de volta uma cheia. Dessa maneira, o 
número total de mensagens no sistema permanece cons¬ 
tante com o tempo, o que permite que elas sejam armaze¬ 
nadas em uma determinada quantidade de memória co¬ 
nhecida antes. 

Se o produtor trabalha mais rapidamente que o consu¬ 
midor, todas as mensagens acabarão cheias, esperando o 
consumidor; o produtor será bloqueado, esperando uma 
vazia voltar. Se o consumidor trabalhar mais rapidamente, 
então o inverso acontece: todas as mensagens estarão vazi¬ 
as esperando o produtor enchê-las; o consumidor será blo¬ 
queado, esperando uma mensagem cheia. 

Muitas variantes são possíveis com passagem de men¬ 
sagem. Para os iniciantes, vejamos como as mensagens são 
endereçadas. Uma maneira é atribuir a cada processo um 
endereço único e ter as mensagens endereçadas para pro¬ 
cessos. Uma maneira diferente é inventar uma nova estru¬ 
tura de dados, chamada caixa de correio ( mailbox). Uma 
caixa de correio é um lugar para armazenar um certo nú¬ 
mero de mensagens, em geral, especificado quando a cai¬ 
xa de correio é criada. Quando as caixas de correio são 
utilizadas, os parâmetros de endereço nas chamadas SEND 
e receive são caixas de correio, não processos. Quando um 
processo tenta enviar para uma caixa de correio que está 
cheia, ele é suspenso até que uma mensagem seja removi¬ 
da dessa caixa de correio, dando espaço para uma nova. 

Para o problema dos produtores e dos consumidores, 
ambos, produtor e consumidor, criariam caixas de correio 
suficientemente grandes para armazenar A'mensagens. 0 
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#define N 100 

void producer(void) 

{ 

int item; 
message m; 

while (TRUE) { 

produce Jtem (&item); 
receive(consumer, &m); 
build_message(&m, item); 
send(consumer, &m); 

} 

} 


/* número de entradas no buffer 7 


/* buffer de mensagem 7 


/* gera algo para colocar no buffer 7 
/* espera chegar uma vazia 7 
/* constrói uma mensagem para enviar 7 
/* envia o item para o consumidor 7 


void consumer(void) 

{ 

int item, i; 
message m; 

for (i = 0; i < N; i++) send(producer, &m); 
while (TRUE) { 

receive(producer, &m); 
extract_item(&m, &item); 
send(producer, &m); 
consumejtem (item); 

} 

} 


/* envia N vazias 7 

/* recebe a mensagem contendo o item 7 
/* extrai o item da mensagem 7 
/* envia de volta resposta vazia 7 
/* faz algo com o item 7 


Figura 2-15 0 problema dos produtores e dos consumidores com TV mensagens. 


produtor enviaria mensagens contendo dados para a caixa 
de correio do consumidor, e o consumidor enviaria men¬ 
sagens vazias para a caixa de correio do produtor. Quando 
as caixas de correio são utilizadas, o mecanismo de arma¬ 
zenamento é claro: a caixa de correio do destino armazena 
mensagens que foram enviadas para o processo de destino 
mas ainda não foram aceitas. 

0 outro extremo de ter caixas de correio é eliminar todo 
armazenamento. Quando essa abordagem é adotada, se o 
SEND é feito antes do receiye, o processo de envio é bloque¬ 
ado até que o receiye aconteça, momento em que a men¬ 
sagem pode ser copiada diretamente do remetente para o 
destinatário, sem nenhum armazenamento intermediário. 
De maneira semelhante, se o RECEIYE é feito primeiro, o 
destinatário é bloqueado até que um SEND aconteça. Essa 
estratégia é freqüentemente conhecida como rendez-vous. 
É mais fácil de implementar do que um esquema de men¬ 
sagens armazenadas mas é menos flexível porque o reme¬ 
tente e o destinatário são forçados a executar em lockstep, 
i. e., intercalando ação e bloqueio, de acordo com o ritmo 
do processo mais lento. 

A comunicação entre processos de usuário no MINIX (e 
no UNIX) é via pipes, que são, efetivamente, caixas de cor¬ 
reio. A única diferença real entre um sistema de mensa¬ 
gem com caixas de correio e o mecanismo de pipes é que 
os pipes não conservam os limites da mensagem. Em ou¬ 
tras palavras, se um processo gravar 10 mensagens de 100 
bytes em um pipe e outro processo ler 1.000 bytes desse 
pipe, o leitor receberá todas as 10 mensagens imediatamen¬ 


te. Com um verdadeiro sistema de mensagens, cada READ 
deve retornar só uma mensagem. Naturalmente, se os pro¬ 
cessos concordarem em sempre ler e gravar mensagens de 
tamanho fixo no pipe, ou em finalizar cada mensagem com 
um caractere especial (p. ex., uma quebra de linha), não 
haverá nenhum problema. Os processos que constituem o 
sistema operacional minix utilizam um verdadeiro esque¬ 
ma de mensagens de tamanho fixo para comunicação en¬ 
tre eles. 

2.3 PROBLEMAS CLÁSSICOS DE CIP 

A literatura de sistemas operacionais está repleta de pro¬ 
blemas interessantes que foram amplamente discutidos e 
analisados. Nas seções a seguir, examinaremos três dos pro¬ 
blemas mais conhecidos. 

2.3.1 O Problema dos Filósofos 
Jantando 

Em 1965, Dijkstra propôs e resolveu um problema de 
sincronização que ele chamou de problema dos filóso¬ 
fos jantando. Desde essa época, todo mundo que inventa¬ 
va outra primitiva de sincronização sentia-se obrigado a 
demonstrar 0 quão maravilhosa a nova primitiva era, mos¬ 
trando 0 quão elegantemente ela resolvia 0 problema dos 
filósofos jantando. O problema pode ser exposto de uma 
maneira simples, como segue. Cinco filósofos estão senta- 
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Figura 2-16 Hora do jantar no Departamento de Filosofia. 


dos ao redor de uma mesa circular. Cada filósofo tem um 
prato de espaguete. 0 espaguete está tão escorregadio que 
o filósofo precisa de dois garfos para comê-lo. Entre cada 
par de pratos está um garfo. A organização da mesa está 
ilustrada na Figura 2-16. 

A vida de um filósofo consiste em períodos alternados 
de comer e de pensar. (Isso é uma abstração, mesmo para 
filósofos, mas as demais atividades são irrelevantes aqui.) 
Quando um filósofo fica com fome, ele tenta pegar os gar¬ 
fos da esquerda e da direita, um de cada vez, em qualquer 
ordem. Se tiver sucesso em pegar dois garfos, ele come por 
um tempo e, então, coloca os garfos na mesa e continua a 
pensar. A pergunta-chave é: você pode escrever um progra¬ 
ma para cada filósofo fazer o que se supõe que ele deve 
fazer e nunca ficar imobilizado? (Foi indicado que o re¬ 
quisito de dois garfos é um pouco artificial; talvez devêsse¬ 
mos trocar a comida italiana por comida chinesa, substi¬ 
tuindo o espaguete por arroz, e os garfos por pauzinhos.) 

A Figura 2-17 mostra a solução óbvia. 0 procedimento 
take_Jork espera ate' que o garfo especificado esteja dispo¬ 
nível e, então, pega-o. Infelizmente, a solução óbvia está 
errada. Suponha que todos os cinco filósofos peguem seus 
garfos esquerdos simultaneamente. Nenhum será capaz de 
pegar seus garfos direitos e haverá um impasse. 

Poderíamos modificar o programa de modo que depois 
de pegar o garfo esquerdo, o programa verificasse se o gar¬ 
fo direito está disponível. Se não estiver, o filósofo coloca 
na mesa o esquerdo, espera algum tempo e, então, repete o 
processo inteiro. Essa proposta também fracassa, embora 
por uma razão diferente. Com um pouquinho de má sorte, 
todos os filósofos poderiam iniciar o algoritmo simultane¬ 
amente, pegando seus garfos esquerdos, vendo que seus 
garfos direitos não estão disponíveis, colocando na mesa 


seus garfos esquerdos, esperando, pegando seus garfos es¬ 
querdos novamente simultaneamente e assim por diante, 
eternamente. Uma situação como essa, em que todos os 
programas continuam a executar indefinidamente mas não 
conseguem fazer qualquer progresso é chamada fome. (E 
chama-se fome mesmo quando o problema não ocorre em 
um restaurante italiano ou chinês.) 

Agora você pode pensar: “Se os filósofos apenas espe¬ 
rassem um tempo aleatório em vez do mesmo tempo após 
não conseguir pegar o garfo da mão direita, a chance de 
que tudo continuaria em lochstep por um longo período é 
muito pequena”. Essa observação é verdadeira, mas em 
alguns aplicativos talvez se prefira uma solução que sem¬ 
pre funciona e não possa falhar devido a uma série impro¬ 
vável de números aleatórios. (Pense no controle de segu¬ 
rança em uma usina nuclear.) 

Um aprimoramento na Figura 2-17 que não resulta em 
impasse nem em fome é proteger as cinco declarações que 
se seguem à chamada a thuik com um semáforo binário. 
Antes de começar a pegar os garfos, um filósofo faria um 
DOW em mutex. Depois de substituir os garfos, ele faria 
um up em mutex. De um ponto de vista teórico, essa solu¬ 
ção é adequada. De um ponto de vista prático, ela apresen¬ 
ta uma falha em termos de desempenho: só um filósofo 
pode estar comendo de cada vez. Com cinco garfos dispo¬ 
níveis, deveríamos ser capazes de permitir que dois filóso¬ 
fos comessem ao mesmo tempo. 

A solução apresentada na Figura 2-18 é correta e tam¬ 
bém permite o paralelismo máximo para um número ar¬ 
bitrário de filósofos. Ela utiliza uma matriz, State, para 
monitorar se um filósofo está comendo, se está pensando, 
ou se está com fome (tentando pegar garfos). Um filósofo 
só pode passar para o estado “comendo” se nenhum vizi- 
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#define N 5 


/* número de filósofos *! 


void philosopher(int i) 

{ 

while (TRUE) { 
think(); 
take_fork(i); 
take_fork((i+1 ) % N); 
eat(); 
put fork(i); 
put fork((i+1 ) % N); 

} 

} 


/* número do filósofo, de 0 a 4 */ 


/* filósofo está pensando */ 

/* pega o garfo esquerdo */ 

/* pega o garfo direito; % é o operador de módulo */ 
/* nham-nham, espaguete */ 

/* coloca o garfo esquerdo de volta na mesa */ 

*/ coloca o garfo direito de volta na mesa 7 


Figura 2-17 Uma "não-solução" para o problema dos filósofos jantando. 


nho estiver comendo. Os vizinhos do filósofo i são defini¬ 
dos pelas macros LEFT e RIGHT. Em outras palavras, se o i 
é 2,LEFTé 1 e RIGHT é 3- 

0 programa utiliza uma matriz de semáforos, um por 
filósofo, assim os filósofos com fome podem bloquear se os 
garfos necessários estiverem ocupados. Note que cada pro¬ 
cesso executa o procedimento philosopher como seu códi¬ 
go principal. Mas, take_Jorks,put_Jorks e test, são proce¬ 
dimentos comuns e não processos separados. 

2.3.2 O Problema dos Leitores e dos 
Escritores 

0 problema de filósofos jantando é útil para modelar 
processos que estão competindo por acesso exclusivo a um 
número limitado de recursos, como dispositivos de E/S. 
Outro problema famoso é o problema dos leitores e dos es¬ 
critores (Courtoise/«/., 1971), que modela o acesso a um 
banco de dados. Imagine, por exemplo, sistema de reservas 
de uma companhia aérea, com muitos processos concor¬ 
rentes querendo ler e escrever. É permitido ter múltiplos 
processos lendo o banco de dados ao mesmo tempo, mas, 
se um processo estiver atualizando (escrevendo) o banco 
de dados, nenhum outro processo poderá ter acesso ao ban¬ 
co de dados, nem mesmo leitores. A pergunta é: como você 
programa os leitores e os escritores? Uma solução é mos¬ 
trada na Figura 2-19. 

Nesta solução, o primeiro leitor que recebe acesso ao 
banco de dados faz um DOWN no semáforo db. Os leitores 
subseqüentes meramente incrementam um contador rc. À 
medida que os leitores saem, eles decrementam o contador 
e o último faz um UP no semáforo, permitindo que um 
escritor bloqueado, se houver um, entre. 

A solução apresentada aqui contém implicitamente uma 
decisão sutil que vale comentar. Suponha que enquanto 
um leitor esteja usando o banco de dados, outro leitor apa¬ 
reça. Como ter dois leitores ao mesmo tempo não é um 
problema, o segundo leitor é admitido. Um terceiro leitor e 
os leitores subseqüentes também podem ser admitidos, se 
aparecerem. 

Agora suponha que um escritor apareça. 0 escritor não 
pode ser admitido no banco de dados, uma vez que os es¬ 


critores devem ter acesso exclusivo. Então, o escritor é sus¬ 
penso. Mais tarde, aparecem outros leitores. Contanto que 
pelo menos um leitor ainda esteja ativo, os leitores subse¬ 
qüentes são admitidos. Como uma conseqüência dessa es¬ 
tratégia, contanto que haja um estoque constante de leito¬ 
res, todos eles entrarão logo que chegarem. O escritor será 
mantido suspenso até que nenhum leitor esteja presente. 
Se um novo leitor chegar, digamos, a cada 2 segundos, e 
cada leitor levar 5 segundos para fazer seu trabalho, o es¬ 
critor nunca entrará. 

Para evitar essa situação, o programa poderia ser escri¬ 
to de maneira ligeiramente diferente: quando um leitor 
chega e um escritor está esperando, o leitor é suspenso atrás 
do escritor em vez de ser admitido imediatamente. Dessa 
maneira, um escritor precisa esperar os leitores que esta¬ 
vam ativos quando ele chegou para terminar, mas não pre¬ 
cisa esperar leitores que vieram depois dele. A desvanta¬ 
gem dessa solução é que ela obtém menor paralelismo e, 
portanto, tem desempenho inferior. Courtois e outros apre¬ 
sentaram uma solução que dá prioridade aos escritores. 
Para detalhes, sugerimos a leitura do seu paper. 

2.3.3 O Problema do Barbeiro 
Adormecido 

Outro problema clássico de CIP acontece em uma bar¬ 
bearia. A barbearia tem um barbeiro, uma cadeira de bar¬ 
beiro e n cadeiras para os clientes esperarem, se houver 
algum, sentados. Se não houver nenhum cliente presente, 
0 barbeiro senta-se na sua cadeira e dorme, como ilustra¬ 
do na Figura 2-20. Quando um cliente chega, ele tem de 
acordar 0 barbeiro. Se outros clientes chegarem enquanto 
0 barbeiro estiver cortando 0 cabelo de um cliente, eles sen- 
tam-se (se houver cadeiras vazias) ou saem da barbearia 
(se todas as cadeiras estiverem cheias). 0 problema é pro¬ 
gramar 0 barbeiro e os clientes sem cair em condições de 
corrida. 

Nossa solução utiliza três semáforos: customers , que 
conta os clientes que esperam (excluindo 0 cliente na ca¬ 
deira do barbeiro, que não está esperando), barbers, 0 
número de barbeiros que estão desocupados, esperando cli¬ 
entes (0 ou 1) e mutex, que é utilizado para exclusão mú- 
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#define N 5 

#define LEFT (i-1 )%N 

#define RIGHT (i+1)%N 

#defineTHINKING 0 
#define HUNGRY 1 

#define EATING 2 

typedef int semaphore; 
int state[N]; 
semaphore mutex = 1; 
semaphore s[N]; 

void philosopher(int i) 

{ 

while (TRUE) 

{think(); 

take_forks(i); 

eat(); 

put_forks(i); 

} 

} 

void take_forks(int i) 

{ 

down(&mutex); 
state[i] = HUNGRY; 
test(i); 
up(&mutex); 
down(&s[i]); 

} 

void put_forks(i) 

{ 

down(&mutex); 

State [i] = THINKING; 
test(LEFT); 
test(RIGHT); 
up(&mutex); 

} 


/* número de filósofos 7 

/* número do vizinho à esquerda de i 7 

/* número do vizinho à direita de i 7 

/* filósofo está pensando 7 

/* filósofo está tentando pegar os garfos 7 

/* filósofo está comendo 7 

/* semáforos são um tipo especial de int 7 
/* matriz para monitorar o estado de todos 7 
/* exclusão mútua para regiões críticas 7 
/* um semáforo por filósofo 7 

/* i: número do filósofo, de 0 a N-1 7 

/* repete eternamente 7 
/* filósofo está pensando 7 
/* pega dois garfos ou bloqueia 7 
/* nham-nham, espaguete 7 
/* coloca de volta os garfos na mesa 7 


/* i: número do filósofo, de 0 a N-1 7 
/* entra na região crítica 7 

/* registra o fato de que o filósofo está com fome 7 
I* tenta pegar 2 garfos 7 
/* sai da região crítica 7 
/* bloqueia se os garfos não foram pegos 7 


/* i: número do filósofo, de 0 a N-1 7 

/* entra na região crítica 7 

/* filósofo terminou de comer 7 

/* vê se o vizinho esquerdo agora pode comer 7 

/* vê se o vizinho direito agora pode comer 7 

/* sai da região crítica 7 


void test(i) /* i: número do filósofo, de 0 a N-1 7 

{ 

if (state[i] == HUNGRY && state[LEFT] != EATING && state[RIGHT] != EATING) { 
state[i] = EATING; 
up(&s[i]); 

} 

} 


Figura 2-18 Uma solução para o problema dos filósofos jantando. 


tua. Também precisamos de uma variável, waiting. que 
também conta os clientes que esperam. É essencialmente 
uma cópia de customers. A razão para ter waiting é que 
não há nenhum meio de ler o valor atual de um semáforo. 
Nessa solução, um cliente que entra na loja tem de verifi¬ 
car o número de clientes que estão esperando. Se for inferi¬ 
or ao número de cadeiras, ele permanece; caso contrário, 
sai. 

Nossa solução é mostrada na Figura 2-21. Quando o 
barbeiro chega para trabalhar de manhã, ele executa o pro¬ 
cedimento barber, o que o faz bloquear no semáforo cus¬ 
tomers até alguém chegar. Ele, então, vai dormir como 
mostrado na Figura 2-20. 


Quando um cliente chega, ele executa customer, co¬ 
meçando por adquirir mutex para entrar em uma região 
crítica. Se outro cliente entrar logo depois, não será capaz 
de fazer qualquer coisa até que o primeiro tenha liberado 
mutex. O cliente, então, verifica se o número de clientes 
esperando é inferior ao número de cadeiras. Se não, libera 
mutex e sai sem cortar o cabelo. 

Se houver uma cadeira disponível, o cliente incremen¬ 
ta a variável de número inteiro waiting. Então, ele faz um 
UP no semáforo customers, acordando assim o barbeiro. 
Nesse ponto, o cliente e o barbeiro estão ambos acordados. 
Quando o cliente libera mutex, o barbeiro o pega, faz al¬ 
guma arrumação e começa o corte de cabelo. 
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typedef int semaphore; 
semaphore mutex = 1; 
semaphore db = 1; 
intrc = 0; 

void reader(void) 

{ 

while (TRUE) { 

down(&mutex); 
rc = rc + 1; 

if (rc == 1) down(&db); 

up(&mutex); 

read_data base(); 

down(&mutex); 

rc = rc - 1; 

if (rc == 0) up(&db); 

up(&mutex); 

use_data_read(); 

} 

} 


/* utilize sua imaginação */ 

/* controla o acesso a ’rc’ */ 

/* controla o acesso ao banco de dados */ 

/* número de processos lendo ou querendo ler */ 


/* repete eternamente */ 

I* obtém acesso exclusivo a 'rc' */ 
/* mais um leitor agora */ 

/* se este for o primeiro leitor... */ 
/* libera acesso exclusivo a 'rc' */ 
/* acessa os dados */ 

/* obtém acesso exclusivo a 'rc' */ 
/* um leitor a menos agora */ 

/* se este for o último leitor... */ 

/* libera acesso exclusivo a 'rc' */ 
/* região não-crítica */ 


writer(void) 

{ 

while (TRUE) { 

{think_up_data(); 
down(&db); 
write_data_base(); 
up(&db); 

} 

} 


/* repete eternamente */ 

/* região não-crítica */ 

/* obtém acesso exclusivo */ 
/* atualiza os dados */ 

/* libera acesso exclusivo */ 


Figura 2-19 Unia solução para o problema dos leitores e dos escritores. 



Figura 2-20 0 barbeiro adormecido. 
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Quando o corte de cabelo termina, o cliente sai do pro¬ 
cedimento e sai da barbearia. Diferentemente de nossos 
exemplos anteriores, não há nenhum laço para o cliente 
porque cada um recebe só um corte de cabelo. O barbeiro, 
entretanto, faz um laço, tentando receber o próximo clien¬ 
te. Se um cliente estiver presente, outro corte de cabelo é 
feito. Se não, o barbeiro vai dormir 

A propósito, vale indicar que embora os problemas dos 
leitores e dos escritores e o do barbeiro adormecido não 
envolvam transferência de dados, eles ainda pertencem à 
área de CIP porque envolvem sincronização entre múlti¬ 
plos processos. 

2.4 AGENDAMENTO DE PROCESSO 

Nos exemplos das seções anteriores, com freqüência ti¬ 
vemos situações em que dois ou mais processos (p. ex.. pro¬ 
dutor e consumidor) eram logicamente executáveis. Quan¬ 
do mais de um processo é executável, o sistema operacio¬ 
nal deve decidir qual executar primeiro. A parte do sistema 
operacional que toma essa decisão é chamada agendador; 


o algoritmo que ele utiliza é chamado algoritmo de agen- 
damento. 

De volta aos velhos dias dos sistemas de lote com entra¬ 
da na forma de imagens de cartões em uma fita magnéti¬ 
ca, o algoritmo de agendamento era simples: apenas exe¬ 
cute o próximo trabalho na fila. Com sistemas de compar¬ 
tilhamento de tempo, o algoritmo de agendamento é mais 
complexo, uma vez que, frequentemente, há múltiplos usu¬ 
ários esperando serviço e pode haver um ou mais fluxos de 
lote também (p. ex. em uma companhia de seguro, para 
processar pedidos). Mesmo em computadores pessoais, pode 
haver vários processos iniciados pelo usuário competindo 
pela CPU, para não mencionar trabalhos em segundo pla¬ 
no. como servidores de rede ou correio eletrônico enviando 
ou recebendo mensagens. 

.Antes de examinar algoritmos de agendamento especí¬ 
ficos, devemos pensar no que o agendador está tentando 
obter. Afinal de contas, o agendador está preocupado em 
decidir sobre política, não em fornecer um mecanismo. 
Vários critérios vêm à mente sobre o que constitui um bom 
algoritmo de agendamento. Algumas possibilidades inclu¬ 
em: 


#define CHAIRS 5 

typedef int semaphore; 

semaphore customers = 0; 
semaphore barbers = 0; 
semaphore mutex = 1; 
int waiting = 0; 

void barber(void) 

{ 

while (TRUE) { 

down (customers); 

down(mutex); 

waiting = waiting - 1; 

up(barbers); 

up(mutex); 

cut hair(); 

} 

} 


/* número de cadeiras para esperar clientes */ 

/* utilize sua imaginação */ 

/* número de clientes que esperam serviço */ 

/* número de barbeiros que esperam clientes */ 

/* para exclusão mútua */ 

/* clientes estão esperando (não cortando cabelo) */ 


/* vai dormir se o número de clientes for 0 */ 

I* adquire acesso a 'waiting' */ 

/* decrementa a conta de clientes esperando */ 

/* um barbeiro está agora pronto para cortar o cabelo */ 
/* libera 'waiting’ */ 

/* corta o cabelo (fora da região crítica) */ 


void customer(void) 

{ 

down (mutex); 
if (waiting < CHAIRS) { 

waiting = waiting + 1; 

up(customers); 

up(mutex); 

down (barbers) ; 

get_haircut(); 

} else { 

up(mutex); 

} 

} 


/* entra na região crítica */ 

/* se não houver cadeiras livres, vai embora */ 

/* incrementa a contagem de clientes esperando */ 
/* acorda o barbeiro se necessário */ 

/* libera o acesso a 'waiting' */ 

/* vai dormir se o número de barbeiros livres for 0 */ 
/* senta-se e é atendido */ 

/* a barbearia está cheia; não espera */ 


Figura 2-21 Uma solução para o problema do barbeiro adormecido. 
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y 1. A imparcialidade — assegura que cada processo 
receba sua justa parte da CPU. 

2. A eficiência — mantém a CPU ocupada 100% do 
tempo. 

3- Tempo de resposta — minimiza o tempo de res¬ 
posta para usuários interativos. 

4. Turnaround — minimiza o tempo que os usuá¬ 
rios de lote devem esperar pela saída. 

5. nroughput — maximiza o número de jobs pro¬ 
cessados por hora. 

Uma rápida análise mostrará que algumas dessas metas 
são contraditórias. Para minimizar o tempo de resposta para 
usuários interativos, o agendador não deve executar ne¬ 
nhum trabaího de lote (exceto talvez entre 3 e 6h, quando 
todos os usuários interativos estão confortáveis em suas 
camas). Mas os usuários de lote provavelmente não gosta¬ 
rão desse algoritmo; ele viola o critério 4. Pode ser demons¬ 
trado (Kleinrock, 1975) que qualquer algoritmo de agen- 
damento que favorece alguma classe de trabalho acaba 
prejudicando outra classe de trabalho. A quantidade de tem¬ 
po de CPU disponível é finita, afinal de contas. Para dar 
mais a um usuário, você tem de dar menos a outro usuá¬ 
rio. Assim é a vida. 

Uma complicação com que os agendadores têm de li¬ 
dar é que cada processo é único e imprevisível. Alguns gas¬ 
tam muito tempo esperando E/S de arquivo, enquanto ou¬ 
tros utilizariam a CPU durante horas por vez se lhe fosse 
dada a chance. Quando o agendador começa a executar 
algum processo, ele nunca sabe com certeza quanto tempo 
levará até que o processo bloqueie, seja para E/S, um se¬ 
máforo ou por qualquer outra razão. Para certificar-se de 
que nenhum processo executará por muito tempo, quase 
todos os computadores têm um temporizador ou um reló¬ 
gio eletrônico interno, que causa uma interrupção perio¬ 
dicamente. Uma freqüência de 50 ou 60 vezes por segundo 
(chamada 50 ou 60 Hertz e abreviado como Hz) é comum, 
mas em muitos computadores o sistema operacional pode 
configurar a freqüência de temporização para qualquer 
valor que ele quiser. Em cada interrupção de relógio, o sis¬ 
tema operacional começa a executar e decide se o processo 
atualmente em execução deve ter permissão para continu¬ 
ar, ou se teve tempo suficiente de CPU até o momento e 
deve ser suspenso para dar a CPU a outro processo. 

A estratégia de permitir processos que são logicamente 
executáveis serem temporariamente suspensos é chamada 


agendamento preemptivo, e está em oposição ao méto¬ 
do de executar até concluir dos antigos sistemas de lote. 
Esse método também é chamado agendamento não-pre- 
emptivo. Como vimos ao longo deste capítulo, um proces¬ 
so pode ser suspenso em um instante arbitrário, sem aviso, 
para que outro processo possa ser executado. Isso leva a 
condições de corrida e precisa de semáforos, de monitores, 
de mensagens ou de algum outro método sofisticado para 
evitá-las. Por outro lado, a política de deixar um processo 
executar o quanto quiser significaria que um processo cal¬ 
culando n até um bilhão de casas poderia negar serviço a 
todos os outros processos indefinidamente. 

Portanto, embora algoritmos de agendamento não-pre- 
emptivo sejam simples e fáceis de implementar, eles nor¬ 
malmente não são adequados para sistemas de propósito 
geral com múltiplos usuários competindo. Por outro lado, 
para um sistema dedicado, como um servidor de banco de 
dados, pode ser bastante razoável para o processo-mestre 
iniciar um processo-filho trabalhando em uma requisição 
e deixá-lo executar até que o processo se complete ou blo¬ 
queie. A diferença do sistema de propósito geral é que todos 
os processos no sistema de banco de dados estão sob o con¬ 
trole de um único mestre, que sabe o que cada filho fará e 
quanto tempo levará. 

2.4.1 Agendamento Round Robin 

Agora vejamos alguns algoritmos de agendamento es¬ 
pecíficos. Um dos algoritmos mais simples, mais antigos e 
mais amplamente utilizados é o round robin. A cada pr o- 
cesso é atribuído um intervalo de tempo, chamado de seu 
qüãntum, durante o qual lhe é permitido executai) Se o 
processo ainda está executando no fim do quantum, é feita 
a preempção da CPU e ela é dada a outro processo. Se o 
processo bloqueou ou terminou antes de o quantum ter 
passado, é feita a comutação da CPU quando o processo 
bloqueia, naturalmente. O round robin é fácil de imple¬ 
mentar. Tudo que precisamos que o agendador faça é man¬ 
ter uma lista de processos executáveis, como mostrado na 
Figura 2-22(a). Quando o processo utiliza todo seu quan¬ 
tum, ele é posto no fim da lista, como mostrado na Figura 
2-22(b) 

A única questão interessante relacionada com o round 
robin é a duração do quantum. Alternar de um processo 
para outro requer uma certa quantidade de tempo para fazer 


Processo 

atual 


Próximo 

processo 


Processo 

atual 



(a) 


(b) 


Figura 2-22 Agendamento round robin. (a) Lista de processos executáveis, (b) Lista de processos executáveis depois que B utiliza 
todo seu quantum. 
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a administração — salvar e carregar registradores e ma¬ 
pas de memória, atualizar várias tabelas e listas, etc. Supo¬ 
nha que essa comutação de processo ou comutação de 
contexto, como às vezes é chamada, leve 5ms. Também 
suponha que o quantum é definido como 20ms. Com esses 
parâmetros, depois de fazer 20ms de trabalho útil, a CPU 
gastará 5ms na comutação de processos. Vinte por cento do 
tempo da CPU serão desperdiçados em trabalho adminis¬ 
trativo. 

Para melhorar a eficiência da CPU, poderíamos confi¬ 
gurar o quantum como, digamos, 500ms. Agora, o tempo 
desperdiçado é inferior a 1%. Mas considere o que acontece 
em um sistema de compartilhamento de tempo se dez usu¬ 
ários interativos pressionarem a tecla Enter mais ou me¬ 
nos ao mesmo tempo. Dez processos serão postos na lista 
de processos executáveis. Se a CPU estiver desocupada, o 
primeiro iniciará imediatamente, o segundo não poderá 
iniciará até 1/2 s mais tarde e assim por diante. O infeliz 
último da fila irá esperar 5 s antes de ter uma chance, su¬ 
pondo que todos os outros utilizam seus quanta inteiros. A 
maioria dos usuários achará horrível uma resposta de 5 s 
para um comando. O mesmo problema pode ocorrer em 
um computador pessoal que suporta multiprogramação. 

A conclusão pode ser formulada como segue: configu¬ 
rando o quantum com um tempo muito pequeno, ocor¬ 
rem muitas comutações de processo, e a eficiência da CPU 
é reduzida; mas configurando-o com um tempo muito lon¬ 
go, a resposta pode ser pobre para curtas requisições inte¬ 
rativas. Um quantum em torno de lOOms é freqüentemen- 
te um compromisso razoável. 

2.4.2 Agendamento por Prioridade 

0 agendamento round robin faz a suposição implícita 
de que todo processo é igualmente importante. Com fre¬ 
quência, as pessoas que possuem e operam computadores 
multiusuários têm idéias diferentes sobre tal assunto. Em 
uma universidade, a ordem de prioridade pode ser direto¬ 
res primeiro, depois professores, secretários, inspetores e, 
por fim, os alunos. A necessidade de levar em conta fatores 
externos conduz ao agendamento por prioridade. A idéia 
básica é simples e direta: a cada processaeratribuído uma 
prioridade, e o processo executável com a maior prioridade 
recebe permissão para executar. 

Mesmo em um PC com um único proprietário, pode 
haver múltiplos processos, alguns mais importantes que 
outros. Por exemplo, a um processo de servidor que envia 
uma mensagem de correio eletrônico em segundo plano 
deve ser atribuído uma prioridade mais baixa que a um 
processo que exibe um vídeo na tela em tempo real. 

Para evitar que processos de alta prioridade executem 
indefinidamente, o agendador pode diminuir a prioridade 
do processo atualmente em execução em cada tique de re¬ 
lógio (i. e., a cada interrupção de relógio). Se essa ação 
fizer com que sua prioridade caia para baixo do próximo 
processo com maior prioridade, ocorre uma comutação de 
processo. Alternativamente, a cada processo pode ser atri¬ 


buído um quantum máximo em que lhe é permitido usar 
a CPU continuamente. Quando esse quantum é utilizado, 
é dada uma chance de executar ao próximo processo com 
maior prioridade. 

Asprioridades podem ser atribuídas aos processos está^ 
tica_o u dinan ricámeate. Em~tim computador militar, o pro¬ 
cesso iniciadõ~piIcTgeneral pode começar com prioridade 
100, processos iniciados por coronéis com 90, majores com 
80, capitães com 70, tenentes com 60 e assim por diante. 
Alternativamente, em um centro de computação comerci¬ 
al, trabalhos de alta prioridade podem custar 100 dólares 
por hora; os de média prioridade, 75 dólares por hora; e os 
de baixa prioridade 50 dólares por hora. O sistema UNIX 
tem um comando, nice, que permite que um usuário vo¬ 
luntariamente reduza a prioridade do seu processo, para 
ser gentil (nice) com os outros usuários. Ninguém o utili¬ 
za. 

As prioridades também podem ser atribuídas dinami¬ 
camente pelo sistema para atingir certas metas do sistema. 
Por exemplo, alguns processos são altamente associados a 
E/S e gastam a maior parte do seu tempo esperando a E/S 
completar-se. Sempre que esse processo quiser a CPU, ele 
deve receber a CPU imediatamente, para deixá-lo iniciar 
sua próxima requisição de E/S, que pode, então, proceder 
em paralelo com outro processo que realmente faz compu¬ 
tação. Deixando o processo associado a E/S esperar por 
muito tempo pela CPU somente significará fazê-lo ocupar 
memória por um tempo desnecessariamente longo. Um 
algoritmo simples para oferecer bom serviço a processos 
associados a E/S éconfigurar a prioridade como l/f onde/ 
é a fração do último quantum que o processo utilizou. Um 
processo que utilizou só 2ms de seus ÍOOms de quantum 
receberia prioridade 50, enquanto um processo que execu¬ 
tasse 50ms antes de bloquear receberia prioridade 2 e um 
processo que utilizou o quantum inteiro receberia priori¬ 
dade 1. 

Muitas vezes é conveniente agrupar processos em clas¬ 
ses de prioridade e utilizar agendamento por prioridade 
entre as classes, mas agendamento por round robin den¬ 
tro de cada classe. A Figura 2-23 mostra um sistema com 
quatro classes de prioridade. O algoritmo de agendamento 
é como segue: contanto que haja processos executáveis em 
classe de prioridade 4, apenas execute cada um pelo tempo 
do seu quantum, no modo round robin e nunca se inco¬ 
mode com classes de prioridade mais baixas. Se a classe de 
prioridade 4 estiver vazia, então, execute os processos clas¬ 
se 3 por round robin. Se as classes 4 e 3 estiverem vazias, 
então, execute a classe 2 por round robin e assim por di¬ 
ante. Se as prioridades não forem ajustadas ocasionalmente, 
as classes de prioridade mais baixa podem passar fome até 
morrer. 

2.4.3 Múltiplas Filas 

Um dos agendadores de prioridade mais antigos estava 
no CTSS (Corbato et al, 1962). O CTSS tinha o problema 
de que a comutação de processos era muito lenta porque 
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Figura 2-23 Um algoritmo de agendamento com quatro classes de prioridade. 


os 7094 podiam armazenar só um processo na memória. 
Cada comutação significava enviar 0 processo atual para 0 
disco e ler um novo processo do disco. Os projetistas do 
CTSS rapidamente reconheceram que era mais eficiente 
dar um quantum grande para processos associados à CPU 
de vez em quando, no lugar de dar pequenos quanta com 
freqüência (reduzindo as trocas). Por outro lado, dar a todo 
processo um quantum grande poderia levar a um péssimo 
tempo de resposta, como já vimos. Sua solução foi definir 
classes de prioridade. Processos de classe mais alta eram 
executados pelo tempo de um quantum. Processos na clas¬ 
se de prioridade mais alta seguinte eram executados por 
dois quanta. Os processos na próxima classe eram execu¬ 
tados por quatro quanta e assim por diante. Sempre que 
um processo utilizava todos os quanta permitidos a ele. era 
movido para baixo uma classe. 

Como um exemplo, considere um processo que preci¬ 
sasse computar continuamente por 100 quanta. Inicial¬ 
mente lhe seria dado um quantum, então, fazia-se sua tro¬ 
ca para 0 disco. Da próxima vez, ele receberia dois quanta 
antes de ser feita sua troca a partir do disco. Em sucessivas 
execuções, ele poderia receber 4, 8. 16 , 32 e 64 quanta, 
embora tivesse utilizado apenas 37 dos 64 quanta totais 
para completar seu trabalho. Só 7 trocas seriam necessári¬ 
as (incluindo a carga inicial) em vez de 100 com um algo¬ 
ritmo de round robin puro. Além disso, à medida que 0 
processo afundava cada vez mais nas filas de prioridade, 
ele seria executado com cada vez menos freqüência, pou¬ 
pando a CPU para processos curtos interativos. 

A seguinte política foi adotada para evitar que um pro¬ 
cesso que necessitava executar durante muito tempo ao ser 
iniciado pela primeira vez, mas tornava-se interativo mais 
tarde, fosse punido eternamente. Sempre que uma tecla 
Enter era pressionada em um terminal, 0 processo perten¬ 
cente a esse terminal era movido para a classe de prioridade 
mais alta, na suposição de que ele estava para tornar-se in¬ 
terativo. Um belo dia, um usuário com um processo inten¬ 
samente associado à CPU descobriu que 0 simples fato de 
pressionar Enter várias vezes, aleatoriamente, melhorava 
seu tempo de resposta. Então, ele contou isso a todos os seus 
amigos. Moral da história: 0 funcionamento na prática é 
muito mais difícil do que 0 funcionamento em princípio. 


Muitos outros algoritmos foram utilizados para atribuir 
classes de prioridade a processos. Por exemplo, 0 influente 
sistema XDS 940 (Lampson, 1968), construído em Berke- 
ley, tinha quatro classes de prioridade, chamadas termi¬ 
nal, E/S, quantum breve e quantum longo. Quando um 
processo que estava esperando uma entrada de terminal 
era finalmente acordado, ele entrava na classe de maior 
prioridade (terminal). Quando um processo esperando um 
bloco de disco tornava-se pronto, ele entrava na segunda 
classe. Quando um processo ainda estava executando quan¬ 
do seu quantum era ultrapassado, ele era inicialmente co¬ 
locado na terceira classe. Entretanto, se um processo gas¬ 
tava seu quantum muitas vezes, enquanto estava na fila 
sem bloquear para E/S de terminal ou outra, ele era movi¬ 
do para baixo na fila. Muitos outros sistemas utilizam algo 
semelhante para favorecer usuários interativos sobre pro¬ 
cessos em segundo plano. 

2.4.4 Job Mais Curto Primeiro 

A maioria dos algoritmos anteriores foi projetada para 
sistemas interativos. Agora examinemos um qu e é e speci- 
almente apropriado a jobs em lote, para os quais 0 tempo 
de execução é conhecido de antemão. Em uma compa¬ 
nhia de seguros, por exemplo, as pessoas podem prever exa¬ 
tamente quanto tempo levará para executar um lote de 
1.000 pedidos, uma vez que um trabalho semelhante é fei¬ 
to todos os dias. Quando vários jobs igualmente importan¬ 
tes estão na fila de entrada esperando ser iniciados, 0 agen- 
dador deve utilizar job mais curto primeiro. Veja a Fi¬ 
gura 2-24. Aqui encontramos quatro jobs A. B, C e D com 
tempos de execução de 8, 4,4 e 4 minutos, respectivamen¬ 
te. Executando-os nessa ordem, 0 tempo de retorno parad 
é 8 minutos, para5 é 12, para Cé l6 e para Dé 20 minutos 
para uma média de 14 minutos. 

Agora consideremos a execução desses quatro jobs uti¬ 
lizando job mais curto primeiro, como mostrado na Figu¬ 
ra 2-24 (b). Os tempos de retorno são agora 4, 8, 12 e 20 
minutos para uma média de 11 minutos, job mais curto 
primeiro é provavelmente ótimo. Considere 0 caso de qua¬ 
tro jobs, com tempos de execução de a, b, c e d, respectiva¬ 
mente. O primeiro job acaba no tempo a , 0 segundo acaba 
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Figura 2-24 Um exemplo de agendamento de job mais curto primeiro. 


no tempo b e assim por diante. O tempqjdejtetorno médio é 
(45M-J& + 2c -pdJ/4. É claro que um contribui mais para 
a média que os outros tempos, então, ele deve ser o traba¬ 
lho mais curto, com b vindo em seguida, depois c e, por 
fim, d como o mais longo na medida que ele afeta apenas 
o seu próprio tempo de retorno. 0 mesmo argumento apli¬ 
ca-se igualmente bem a qualquer número d ejobs. 

Como o job mais curto primei rq_sempie produto me- 
nor tempo médio de resposta, seria ótimo se ele pudesse ser 
utilizado para processos interativos também. Em certa 
medida, ele pode ser utilizado. Processos interativos, em 
geral, seguem o padrão de esperar comando, executar co¬ 
mando, esperar comando, executar comando e assim por 
diante. Se considerarmos a execução de cada comando 
como um '‘trabalho” separado, então poderíamos mini¬ 
mizar o tempo total de resposta para executar o mais curto 
primeiro. O único problema é descobrir qual dos processos 
atualmente executáveis é o mais curto. 

-// Uma abordagem é fazer estimativas com base no com¬ 
portamento passado e executar o processo com o menor 
tempo de execução estimado. Suponha que o tempo esti¬ 
mado por comando para um terminal seja T 0 . Agora supo¬ 
nha que sua próxima execução seja medida como Tj. Po¬ 
deríamos atualizar nossa estimativa pegando uma soma 
ponderada desses dois números, isto é, aT n + (l-a)T,. Pela 
escolha de a podemos fazer o processo de estimativa igno¬ 
rar execuções antigas rapidamente, ou lembrar delas du¬ 
rante muito tempo. Com a = 1/2, obtemos sucessivas esti¬ 
mativas de 

T 0 , T/2 + T,/2, To/4 + T, /4 + T/2, T/8 + 

T 0 /8 + T 2 /4 + T/2 

Após três novas execuções, o peso de T 0 na nova estimativa 
caiu para 1/8. 

A técnica de estimar o próximo valor em uma série pe¬ 
gando a média ponderada do valor atual medido e a esti¬ 
mativa anterior é, às vezes, chamada envelhecime nto. Ela 
é aplicável a muitas situações nas quais uma previsão deve 
ser feita com base em valores anteriores. O envelhecimen¬ 
to é especialmente fácil de implementar quando a = 1/2. 
Tudo que é necessário é adicionar o novo valor à estimati¬ 
va atual e dividir a soma por 2 (rotacionando-o 1 bit para 
a direita). 

Vale indicar que o algoritmo do job mais curto primei¬ 
ro só é ótimo quando todos, os jobs estão disponíveis simul¬ 
taneamente. Como um contra exemplo, considere cinco 


jobs. de A até E, com tempos de execução de 2, 4, 1, 1 e 1, 
respectivamente. Seus tempos de chegada são 0, 0, 3. 3 e 3- 

Inicialmente, só A ou B pode ser escolhido, uma vez 
que os outros três jobs não chegaram ainda. Utilizando job 
mais curto primeiro, executaremos os jobs na ordem d, B, 
C, D, E, para uma espera média de 4,6. Entretanto, execu¬ 
tando-os na ordem B, C, D,E,A, obtém-se uma espera média 
de 4,4. 

2.4.5 Agendamento Garantido 

Uma abordagem completamente diferente para agen¬ 
damento é fazer promessas realistas aos usuários sobre o 
desempenho e, então, conviver com elas. Uma promessa 
que é realista e fácil de cumprir é: se houver n usuários 
conectados no momento em que você estiver trabalhando, 
você receberá aproximadamente 1 hi do poder da CPU. De 
maneira semelhante, em um sistema monousuário com n 
processos executando, todas as coisas sendo iguais, cada 
uma deve receber Mn dos ciclos da CPU. 

Para cumprir essa promessa, o sistema deve monitorar 
quanto da CPU cada processo teve. desde sua criação. En¬ 
tão, ele calcula quanto da CPU é atribuído a cada um, isto 
é, o tempo desde a criação dividido por n. Como a quanti¬ 
dade de tempo de CPU que cada processo realmente teve 
também é conhecida, é simples calcular a proporção entre 
o tempo real da CPU e o tempo da CPU atribuído. Uma 
proporção de 0,5 significa que um processo só teve metade 
do que devia ter tido e uma proporção de 2,0 significa que 
um processo teve o dobro do tempo que lhe foi atribuído. O 
algoritmo, então, executará o processo com a proporção 
mais baixa até que sua proporção tenha subido acima do 
seu competidor mais próximo. 

2.4.6 Agendamento por Sorteio 

Embora fazer promessas aos usuários e conviver com 
elas seja uma boa idéia, é difícil implementá-las. Mas ou¬ 
tro algoritmo pode ser utilizado para dar resultados previ¬ 
síveis de maneira semelhante com uma implementação 
muito mais simples. Ele é chamado agendamento por 
sorteio (Waldspurger e Weihl, 1994). 

A idéia básica é dar bilhetes de loteria de processos aos 
vários recursos do sistema, como tempo de CPU. Sempre 
que uma decisão de agendamento tiver de ser feita, um 
bilhete de loteria é escolhido aleatoriamente, e o processo 
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que armazena esse bilhete recebe o recurso. Quando apli¬ 
cado ao agendamento da CPU, o sistema pode realizar sor¬ 
teios 50 vezes por segundo, com cada vencedor recebendo 
20ms do tempo da CPU como prêmio. 

Parafraseando George Orwell, “todos os processos são 
iguais, mas alguns processo são mais iguais”. Os processos 
mais importantes podem receber bilhetes extras, para au¬ 
mentar suas chances de ganhar. Se houver 100 bilhetes e 
um processo destacado receber 20 deles, ele terá 20% de 
chance de ganhar cada loteria. A longo prazo, ele receberá 
aproximadamente 20% da CPU. Ao contrário de um agen- 
dador de prioridade, onde é muito difícil dizer o que uma 
prioridade de 40 realmente significa, aqui a regra é clara: 
um processo que armazena uma fração/dos bilhetes rece¬ 
berá cerca de uma fração /do recurso em questão. 

O agendamento por sorteio tem várias propriedades in¬ 
teressantes. Por exemplo, se um novo processo aparece e 
recebe alguns bilhetes, no próximo sorteio, ele terá uma 
chance de ganhar em proporção ao número de bilhetes que 
possui. Em outras palavras, o agendamento por sorteio é 
altamente responsivo. 

Processos cooperativos podem trocar de bilhetes se de¬ 
sejarem. Por exemplo, quando um processo de cliente en¬ 
via uma mensagem para um processo de servidor e, então, 
bloqueia, ele pode dar todos os seus bilhetes para o sena¬ 
dor, para aumentar a chance de o servidor executar em 
seguida. Quando o servidor tiver terminado, ele devolve os 
bilhetes para que o cliente possa executar novamente. De 
fato, na ausência de clientes, os servidores não precisam de 
nenhum bilhete. 

O agendamento por sorteio pode ser utilizado para re¬ 
solver problemas que são difíceis de gerenciar com outros 
métodos. Um exemplo é um servidor de vídeo em que vári¬ 
os processos estão alimentando sequências de vídeo para 
seus clientes, mas a diferentes taxas de quadros. Suponha 
que os processos precisem de quadros a taxas de 10,20 e 25 
quadros/s. Alocando para esses processos 10, 20 e 25 bilhe¬ 
tes, respectivamente, eles automaticamente dividirão a CPU 
na proporção correta. 

2.4.7 Agendamento de Tempo Real 

Um sistema de tempo real é um sistema em que o tem¬ 
po desempenha um papel essencial. Em geral, um ou mais 
dispositivos físicos externos para o computador geram estí¬ 
mulos, e o computador deve interagir apropriadamente a 
eles dentro de uma quantidade fixa de tempo. Por exem¬ 
plo, o computador em um CD player recebe os bits à medi¬ 
da que eles vêm da unidade e deve convertê-los em música 
dentro de um intervalo de tempo muito apertado. Se o cál¬ 
culo demora muito, a música soará estranha. Outros siste¬ 
mas de tempo real servem para monitorar pacientes em 
uma unidade de terapia intensiva de hospital, o piloto au¬ 
tomático em uma aeronave e o controle de segurança em 
um reator nuclear. Em todos esses casos, receber a resposta 


certa, mas muito tarde é frequentemente tão ruim quanto 
não recebê-la. 

Os sistemas de tempo real são geralmente classificados 
como hard real time, que significa que há prazos finais 
absolutos que devem ser cumpridos, e soft real time, que 
significa que perder um prazo final ocasionalmente é tole¬ 
rável. Em ambos os casos, o comportamento de tempo real 
é alcançado dividindo-se o programa em um número de 
processos, cujo comportamento é previsível e conhecido de 
antemão. Tais processos via de regra tem vida curta e po¬ 
dem executar para concluir em menos de um segundo. 
Quando um evento externo é capturado, é trabalho do agen- 
dador agendar os processos de tal maneira que todos os 
prazos finais sejam cumpridos. 

Os eventos que um sistema de tempo real pode ter de 
responder podem ser classificados mais especificamente 
como periódicos (ocorrendo a intervalos regulares) ou 
aperiódicos (ocorrendo de maneira imprevisível). Um sis¬ 
tema pode ter de responder a múltiplos fluxos periódicos 
de evento. Dependendo de quanto tempo cada evento re¬ 
quer para processamento, talvez nem seja possível mani¬ 
pular todos eles. Por exemplo, se houver m eventos perió¬ 
dicos e o evento i ocorre com um período />, e requer ú, 
segundos de tempo de CPU para gerenciar cada evento, 
então a carga só pode ser gerenciada se 


Um sistema tempo real que satisfaz esse critério é conheci¬ 
do como agendável. 

Como exemplo, considere um sistema de soft real time 
com três eventos periódicos, com períodos de 100, 200 e 
500ms, respectivamente. Se esses eventos exigirem 50,30 e 
100ms de tempo de CPU por evento, respectivamente, o sis¬ 
tema será agendável porque 0,5 + 0,15 + 0,2 <1. Se um 
quarto evento com um período de 1 s for adicionado, o sis¬ 
tema permanecerá agendável contanto que esse evento não 
precise de mais de 150ms de tempo de CPU por ocorrência. 
Nesse cálculo está implícita a suposição de que a sobrecar¬ 
ga de comutação de contexto é tão pequena que pode ser 
ignorada. 

Algoritmos de agendamento de tempo real podem ser 
dinâmicos ou estáticos. O primeiro toma suas decisões de 
agendamento em tempo de execução; o último toma-as 
antes de o sistema começar a executar. Consideremos bre¬ 
vemente alguns dos algoritmos de agendamento de tempo 
real dinâmicos. O algoritmo clássico é o algoritmo de ín¬ 
dice monotônico (Liu e Layland, 1973). De antemão, ele 
atribui a cada processo uma prioridade proporcional à fre¬ 
quência de ocorrência do seu evento desencadeado. Por 
exemplo, um processo que executa a cada 20ms recebe pri¬ 
oridade 50 e um processo que executa a cada lOOms obtém 
prioridade 10. Em tempo de execução, o agendador sem- 
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pre executa o processo pronto de mais alta prioridade, fa¬ 
zendo a preempção do processo em execução se necessá¬ 
rio. Liu e Layland provaram que esse algoritmo é ótimo. 

Outro algoritmo de agendamento de tempo real popu¬ 
lar é o de prazo final mais cedo primeiro. Sempre que 
um evento é capturado, seu processo é adicionado à lista 
de processos prontos. A lista é mantida classificada pelo 
prazo final, o que para um evento periódico é a próxima 
ocorrência do evento. 0 algoritmo executa o primeiro pro¬ 
cesso na lista, aquele com o prazo final mais próximo. 

Um terceiro algoritmo primeiro calcula para cada pro¬ 
cesso a quantidade de tempo que tem de dispensar, chama¬ 
da lassidão. Se um processo requer 200ms e deve termi¬ 
nar em 250ms, sua lassidão é 50ms. 0 algoritmo, chama¬ 
do de menor lassidão, escolhe o processo com a menor 
quantidade de tempo a dispensar. 

Enquanto na teoria é possível transformar um sistema 
operacional de propósito geral em um sistema de tempo 
real utilizando um desses algoritmos de agendamento, na 
prática a sobrecarga de comutação de contexto de sistemas 
de propósito geral é tão grande que o desempenho de tem¬ 
po real só pode ser alcançado para aplicativos com limita¬ 
ções de tempo folgadas. Como conseqüência, a maior par¬ 
te do trabalho em tempo real utiliza sistemas operacionais 
de tempo real especiais que têm certas propriedades impor¬ 
tantes. Em geral, essas incluem tamanho pequeno, tempo 
de interrupção rápido, comutação de contexto rápida, cur¬ 
to intervalo durante o qual as interrupções ficam desativa¬ 
das e a capacidade de gerenciar múltiplos temporizadores 
no intervalo de milissegundos ou microssegundos. 

2.4.8 Agendamento de Dois Níveis 

Ate' agora vínhamos mais ou menos supondo que todos 
os processos executáveis estavam na memória principal. 
Se a memória principal disponível for insuficiente, alguns 
dos processos executáveis terão de permanecer no disco, 
inteiros ou em parte. Essa situação tem implicações im¬ 
portantes para o agendamento, uma vez que o tempo de 
comutação de processo para carregar e executar um pro¬ 
cesso do disco é de ordens de magnitude superior ao tempo 


de comutação para um processo j á pronto na memória prin¬ 
cipal. 

Uma maneira mais prática de lidar com comutação de 
processos em disco é utilizar um agendador de dois níveis. 
Algum subconjunto dos processos executáveis é carregado 
inicialmente na memória principal, como mostrado na 
Figura 2-25(a). O agendador, então, restringe-se a esco¬ 
lher processos apenas desse subconjunto temporariamen¬ 
te. Periodicamente, um agendador de nível mais alto é in¬ 
vocado para remover os processos que estiveram por tempo 
suficiente na memória e carregar processos que estiveram 
muito tempo em disco. Uma vez que a mudança tenha sido 
feita, como na Figura 2-25(b), o agendador de nível mais 
baixo novamente se restringe aos processos em execução 
que estão realmente na memória. Assim, o agendador de 
nível mais baixo fica preocupado com fazer uma escolha 
entre os processos executáveis que estão na memória nesse 
momento, enquanto o agendador de nível mais alto fica 
preocupado com o movimento dos processos de um lado a 
outro entre memória e disco. 

Entre os critérios que o agendador de nível mais alto 
poderia utilizar para tomar suas decisões estão os seguin¬ 
tes: 

1. Quanto tempo se passou desde que o processo foi 
levado para o disco ou para a memória? 

2. Quanto tempo de CPU o processo teve recentemen¬ 
te? 

3. Qual é o tamanho do processo? (Os pequenos não 
atrapalham.) 

4. Qual é o nível de prioridade do processo? 

Aqui, novamente, poderíamos utilizar agendamento por 
roundrobin , prioridade ou qualquer um dos vários outros 
métodos. Os dois agendadores podem ou não utilizar o 
mesmo algoritmo. 

2.4.9 Política versus Mecanismo 

Até agora, vínhamos tacitamente supondo que todos os 
processos no sistema pertenciam a usuários diferentes e 
assim estariam competindo pela CPU. Embora isso freqüen- 



(a) (b) (c) 


Figura 2-25 Um agendador de dois níveis deve mover processos entre disco e memória 
e também eleger processos para executar na memória. Três instantes diferentes de tempo 
são representados por (a), (b) e (c). 
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temente seja verdadeiro, às vezes acontece de um processo 
ter muitos filhos que executam sob seu controle. Por exem¬ 
plo, um processo de sistema de gerenciamento de banco de 
dados pode ter muitos filhos. Cada filho pode trabalhar em 
uma requisição diferente, ou cada um pode ter alguma 
função específica para executar (analisar uma consulta, 
acessar um disco, etc.). É plenamente possível que o pro¬ 
cesso principal tenha uma excelente idéia de quais de seus 
filhos são os mais importantes (ou de tempo crítico) e quais 
são menos. Infelizmente, nenhum dos agendadores discu¬ 
tidos anteriormente aceita qualquer entrada de processos 
de usuário sobre decisões de agendamento. Como resulta¬ 
do, o agendador raramente faz a melhor escolha. 

A solução para esse problema é separar o mecanismo 
de agendamento da política de agendamento. Isso sig¬ 
nifica que o algoritmo de agendamento é parametrizado 
de alguma maneira, mas os parâmetros podem ser preen¬ 
chidos por processos de usuário. Consideremos novamente 
o exemplo do banco de dados. Suponha que o kernel utili¬ 
za um algoritmo de agendamento por prioridade, mas for¬ 
nece uma chamada de sistema por meio da qual um pro¬ 
cesso pode definir (e alterar) as prioridades de seus filhos. 
Assim, o pai pode controlar em detalhe como seus filhos 
são agendados, mesmo que ele não faça o agendamento. 
Aqui o mecanismo está no kernel mas a política é confi¬ 
gurada por um processo de usuário. 

2.5 VISÃO GERAL DE PROCESSOS EM 
MINIX 

Tendo completado nosso estudo dos princípios de ge¬ 
renciamento de processos, comunicação interprocesso e 
agendamento, agora podemos dar uma olhada em como 
eles são aplicados no minix. Diferentemente do UNIX, cujo 
kernel é um programa monolítico e não dividido em mó¬ 
dulos, o MINIX é uma coleção de processos que se comuni¬ 
cam entre si e com processos de usuário utilizando uma 
única primitiva de comunicação interprocesso —a passa¬ 
gem de mensagem. Esse projeto proporciona uma estrutu¬ 
ra mais flexível e modular, tornando fácil, por exemplo, 
substituir o sistema de arquivos inteiro por um completa¬ 
mente diferente, sem nem mesmo precisar recompilar o 
kernel. 

2.5.1 A Estrutura Interna do MINIX 

Vamos começar nosso estudo do minix com uma breve 
visão geral do sistema. 0 minix é estruturado em quatro 
camadas, com cada camada executando uma função bem- 
definida. As quatro camadas são ilustradas na Figura 2-26. 

A camada inferior captura todas as interrupções e traps *, 
faz o agendamento e fornece às camadas mais altas um 


*N. de R. Um trap é uma instrução especial que, quando executada 
pelo processador gera o mesmo efeito de uma interrupção. Um trap 
pode ser visto como uma interrupção ocasionada por software. 


modelo de processos sequenciais independentes que se co¬ 
municam utilizando mensagens. 0 código nessa camada 
tem duas funções principais. A primeira é capturar os traps 
e as interrupções, salvar e restaurar registradores, agendar 
e as demais funções para realmente fazer a abstração de 
processo oferecida para as camadas mais altas funciona¬ 
rem. A segunda é gerenciar a mecânica das mensagens; 
verificar destinos legais, localizar buffers de envio e de re¬ 
cebimento na memória física e copiar bytes do remetente 
para o destinatário. Essa parte da camada que lida com o 
nível mais baixo do gerenciamento de interrupções é escri¬ 
ta em linguagem assembly. 0 resto da camada e todas as 
camadas mais altas são escritos em C. 

A camada 2 contém os processos de E/S, um por tipo de 
dispositivo. Para distingui-los dos processos de usuário 
normais, iremos chamá-los de tarefas, mas as diferenças 
entre tarefas e processos são mínimas. Em muitos siste¬ 
mas, as tarefas de E/S são chamadas de drivers de dis¬ 
positivo; utilizaremos os termos “tarefa" e “driver de dis¬ 
positivo” intercambiavelmente. Uma tarefa é necessária 
para cada tipo de dispositivo, incluindo discos, impresso¬ 
ras, terminais, placas de rede e relógios. Se outros disposi¬ 
tivos de E/S estiverem presentes, também é necessária uma 
tarefa para cada um deles. Uma tarefa, a tarefa de sistema, 
é um pouco diferente, uma vez que não corresponde a qual¬ 
quer dispositivo de E/S. Discutiremos as tarefas no próxi¬ 
mo capítulo. 

Todas as tarefas na camada 2 e todo o código na cama¬ 
da 1 estão vinculados entre si em um único programa bi¬ 
nário chamado kernel. Algumas tarefas compartilham 
sub-rotinas comuns, mas, em geral, são independentes uma 
da outra, são agendadas independentemente e comunicam- 
se utilizando mensagens. Os processadores Intel, desde o 
286, atribuem um entre quatro níveis de privilégio a cada 
processo. Embora as tarefas e o kernel sejam compilados 
juntos, quando o kernel e os manipuladores de interrup¬ 
ções estão executando, eles recebem mais privilégios que 
as tarefas. Portanto, o verdadeiro código do kernel pode 
acessar qualquer parte da memória e qualquer registrador 
do processador — essencialmente, o kertiel pode executar 
qualquer instrução utilizando dados de qualquer lugar no 
sistema. As tarefas não podem executar todas as instruções 
no nível de máquina, nem podem acessar todos os regis¬ 
tradores da CPU, ou todas as partes da memória. Mas elas 
podem acessar regiões da memória que pertencem a pro¬ 
cessos menos privilegiados, para executar uma E/S para 
elas. Uma tarefa, a tarefa de sistema, não faz E/S no senti¬ 
do comum mas existe para fornecer serviços, como copiar 
entre regiões diferentes da memória, para processos que 
não têm permissão para fazer essas coisas sozinhos. Em 
máquinas que não oferecem níveis diferentes de privilégio, 
como processadores Intel mais antigos, tais restrições não 
podem ser impostas, naturalmente. 

A camada 3 contém processos que fornecem serviços 
úteis para os processos de usuário. Esses processos de servi¬ 
dor executam em um nível menos privilegiado que o ker¬ 
nel e as tarefas e não podem acessar portas de E/S direta- 
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Figura 2-26 0 MINIXé estruturado em quatro camadas. 


mente. Eles também não podem acessar memória fora dos 
segmentos atribuídos a eles. 0 gerenciador de memória 
(MM) executa todas as chamadas de sistema do mixix que 
envolvem gerenciamento de memória, como FORK, EXEC e 
BRK. 0 sistema de arquivos (FS) executa todas as cha¬ 
madas de sistema de arquivos, como read, mount e CHDiR. 

Como observamos no início do Capítulo 1, os sistemas 
operacionais fazem duas coisas: gerenciar recursos e for¬ 
necer uma máquina estendida implementando chamadas 
de sistema. No MINIX, o gerenciamento de recursos está em 
grande parte no kernel (camadas 1 e 2) e a interpretação 
de chamadas de sistema está na camada 3- O sistema de 
arquivos foi projetado como um “servidor” de arquivos e 
pode ser movido para uma máquina remota sem quase ne¬ 
nhuma mudança. Isso também se aplica ao gerenciador 
de memória, embora os servidores de memória remotos não 
sejam tão úteis quanto senadores de arquivo remotos. 

Servidores adicionais também podem existir na cama¬ 
da 3. A Figura 2-26 mostra um servidor de rede ali. Embora 
o MINIX, como descrito neste livro, não inclua o servidor de 
rede, seu código-fonte é parte da distribuição padrão do 
MINIX. O sistema pode facilmente ser recompilado para in- 
cluí-lo. 

Esse é um bom lugar para observar que embora os ser¬ 
vidores sejam processos independentes, eles diferem de pro¬ 
cessos de usuário por que são iniciados quando o sistema é 
iniciado e nunca terminam enquanto o sistema está ativo. 
Adicionalmente, embora executem no mesmo nível de pri¬ 
vilégio que os processos de usuário em termos das instru¬ 
ções de máquina que eles têm permissão para executar, 
eles recebem prioridade mais alta de execução que os pro¬ 
cessos de usuário. Para acomodar um novo servidor, o ker¬ 
nel deve ser recompilado. 0 código de inicialização do ker¬ 
nel instala os senadores em entradas privilegiadas na tabe¬ 
la de processos antes de qualquer processo de usuário obter 
permissão para executar. 

Por fim, a camada 4 contém todos os processos de usu¬ 
ário — os shells, editores, compiladores e programas es¬ 
critos pelo usuário. Um sistema em execução normalmen¬ 
te tem algum processo que é iniciado quando o sistema é 
inicializado e que executa eternamente. Por exemplo, um 
daemon é um processo de segundo plano que executa pe¬ 


riodicamente ou sempre espera algum evento, como a che¬ 
gada de um pacote de rede. Em certo sentido, um daemon 
é um servidor que é iniciado independentemente e executa 
como um processo de usuário. Entretanto, diferentemente 
dos servidores verdadeiros instalados em entradas privile¬ 
giadas, esses programas não podem receber o tratamento 
especial do kernel que os processos servidores de memória 
e de arquivos recebem. 

2.5.2 Gerenciamento de Processos no 

MINIX 

Os processos no mixix seguem o modelo geral de pro¬ 
cesso descrito em certa extensão anteriormente neste capí¬ 
tulo. Os processos podem criar subprocessos, que, por sua 
vez, podem criar mais subprocessos, produzindo uma ár¬ 
vore de processos. De fato, todos os processos de usuário no 
sistema inteiro são parte de uma única árvore com init (vej a 
Figura 2-26) na raiz. 

Como essa situação ocorre? Quando o computador é 
ligado, o hardware lê o primeiro setor da primeira trilha do 
disco de inicialização para a memória e executa o código 
que encontra lá. Os detalhes variam dependendo de se o 
disco de inicialização é um disquete ou um disco rígido. 
Em um disquete esse setor contém o programa de iniciali¬ 
zação. Ele é muito pequeno, uma vez que tem de caber em 
um setor. 0 programa de inicialização do MINIX carrega 
um programa maior, o boot. que, então, carrega o sistema 
operacional em si. 

Em contraste, os discos rígidos exigem um passo inter¬ 
mediário. Um disco rígido é dividido em partições, e o 
primeiro setor de um disco rígido contém um pequeno pro¬ 
grama e a tabela de partição do disco. Coletivamente, 
estes são chamados registro-mestre de inicialização 
{master boot record). A parte do programa é executada 
para ler a tabela de partição e selecionar a partição ativa. A 
partição ativa tem um programa de inicialização em seu 
primeiro setor, que é, então, carregado e executado para 
localizar e para iniciar uma cópia do boot na partição, exa¬ 
tamente como acontece quando você inicializa a partir de 
um disquete. 
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Em qualquer dos casos, o boot procura um arquivo de 
múltiplas partes no disquete ou na partição e carrega as 
partes individuais na memória nos locais adequados. As 
partes incluem o kernel, o gerenciador de memória, o sis¬ 
tema de arquivos e init, o primeiro processo de usuário. 
Esse processo de inicialização não é uma operação trivial. 

As operações que estão nos domínios da tarefa de disco e do 
sistema de arquivos devem ser executadas por boot antes 
de essas partes do sistema serem ativadas. Em uma seção 
posterior, retornaremos ao assunto de como o MINIX é ini¬ 
ciado. Por enquanto, basta dizer que uma vez que a opera¬ 
ção de carga esteja completa, o kernel começa a executar. 

Durante sua fase de inicialização, o kernel inicia as 
tarefas e só então o gerenciador de memória, o sistema de 
arquivos e quaisquer outros servidores que executam na 
camada 3 . Quando todos esses tiverem executados e inicia- 
lizados, eles bloquearão, esperando algo para fazer. Quan¬ 
do todas tarefas e servidores estiverem bloqueados, init. o 
primeiro processo de usuário, será executado. Ele já está 
na memória, mas poderia, naturalmente, ser carregado do 
disco como um programa separado uma vez que tudo mais 
está funcionando no momento em que ele é iniciado. En¬ 
tretanto, como init é iniciado só nesse momento e nunca é 
recarregado do disco, é mais fácil apenas incluí-lo no ar¬ 
quivo de imagem de sistema com o kernel , tarefas e servi¬ 
dores. 

Init inicia lendo o arquivo /etc/ttytab, o qual lista to¬ 
dos dispositivos terminais potenciais. Esses dispositivos que 
podem ser utilizados como terminais de login (na distri¬ 
buição-padrão, apenas o console) tem uma entrada no 
campo getty de /etc/ttytab, e init cria um processo-filho 
para cada um desses terminais. Cada filho normalmente 
executa /usr/bin/getty, o qual imprime uma mensagem e 
depois espera um nome ser digitado. Então /usr/bin/login 
é chamado com o nome como seu argumento. Se um ter¬ 
minal particular exigir tratamento especial (p. ex„ uma 
linha discada) /etc/ttytab pode especificar um comando 
(como /usr/bin/stty) para ser executado a fim de iniciar a 
linha antes de executar getty. 

Após um login bem-sucedido ,/bin/login executa o shell 
do usuário (especificado no arquivo /etc/passivord e nor- 
malmente/feAAA ou/usr/bin/ash). O shell espera coman¬ 
dos serem digitados e, então, cria um novo processo para 
cada comando. Dessa maneira, os sbells são os filhos de 
init, os processos de usuário são os netos de init e todos os 
processos de usuário no sistema são parte de uma única 
árvore. 

As duas principais chamadas de sistema do mixix para 
gerenciamento de processos são FORK e EXEC. FORK é o úni¬ 
co meio de criar um novo processo. EXEC permite criar um 
processo para executar um programa especificado. Quan¬ 
do um programa é executado, ele recebe uma parte da 
memória cujo tamanho é especificado no cabeçalho do 
arquivo de programa. Ele mantém essa quantidade de me¬ 
mória durante toda sua execução, embora a distribuição 
entre segmento de dados, segmento de pilha e não-utiliza- 
do possa variar à medida que o processo executa. 


Todas as informações sobre um processo são mantidas 
na tabela de processos, que é dividida entre o kernel, o ge¬ 
renciador de memória e o sistema de arquivos, com cada 
um desses tendo os campos que precisa. Quando um novo 
processo aparece (por FORK), ou um processo antigo ter¬ 
mina (por EXIT ou por um sinal), o gerenciador de memó¬ 
ria primeiro atualiza sua parte na tabela de processos e, 
então, envia mensagens para o sistema de arquivos e para 
o kernel informando-os para fazer o mesmo. 

2.5.3 Comunicação Interprocesso no 
MINIX 

Três primitivas são fornecidas para enviar e para rece¬ 
ber mensagens. Elas são chamadas pelos procedimentos 
de biblioteca de C 

send(dest, &message); 

para enviar uma mensagem ao processo dest, 

receive(source, &message); 

para receber uma mensagem do processo source (ou QUAL¬ 
QUER), e. 

send_rec(src_dst, &message); 

para enviar uma mensagem e esperar uma resposta do 
mesmo processo. O segundo parâmetro em cada chamada 
é 0 endereço local dos dados da mensagem. 0 mecanismo 
de passagem de mensagem no kernel copia a mensagem 
do remetente para 0 destinatário. A resposta (para send_rec) 
sobrescreve a mensagem original. A princípio, esse meca¬ 
nismo de kernel poderia ser substituído por uma função 
que copia mensagens por uma rede para uma função cor¬ 
respondente em outra máquina, implementando um siste¬ 
ma distribuído. Na prática, isso seria algo complicado pelo 
fato de 0 conteúdo dessa mensagem ser, às vezes, ponteiros 
para estruturas de dados grandes, e um sistema distribuído 
também teria de providenciar a cópia dos próprios dados 
pela rede. 

Cada processo ou tarefa pode enviar e receber mensa¬ 
gens de processos e de tarefas em sua própria camada e 
daqueles na camada imediatamente abaixo. Os processos 
de usuário não podem comunicar-se diretamente com as 
tarefas de E/S. 0 sistema impõe essa restrição. 

Quando um processo (0 que também inclui as tarefas 
como um caso especial) envia uma mensagem para um 
processo que atualmente não está esperando uma mensa¬ 
gem, 0 remetente bloqueia até que 0 destino faça um RE- 
CEIYE. Em outras palavras, 0 MINIX utiliza 0 método de ren- 
dez-vous para evitar os problemas de armazenamento de 
mensagens enviadas, mas ainda não recebidas. Embora 
menos flexível que um esquema com armazenamento, ele 
se mostra adequado para esse sistema, e muito mais sim¬ 
ples porque nenhum gerenciamento de buffer é necessá¬ 
rio. 
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2.5.4 Agendamento de Processos no 
MINIX 

0 sistema de interrupções é o que mantém um sistema 
operacional multiprogramado em funcionamento. Os pro¬ 
cessos bloqueiam quando fazem requisições para entrada, 
permitindo que outros processos executem. Quando a en¬ 
trada torna-se disponível, o processo atual em execução é 
interrompido pelo disco, pelo teclado ou por outro hardware. 
0 relógio também gera interrupções utilizadas para certi¬ 
ficar que um processo de usuário em execução que não 
solicitou entrada acabe abandonando a CPU, para dar a 
outro processo sua chance de executar. É trabalho da ca¬ 
mada mais baixa do MINIX ocultar essas interrupções, trans¬ 
formando-as em mensagens. No que diz respeito aos pro¬ 
cessos (e tarefas), quando um dispositivo de E/S completa 
uma operação ele envia uma mensagem para o processo, 
acordando-o e tornando-o executável. 

Cada vez que um processo é interrompido, seja a partir 
de um dispositivo convencional de E/S ou a partir do reló¬ 
gio, há uma oportunidade para determinar qual processo 
merece uma oportunidade de executar. Naturalmente, isso 
também deve ser feito sempre que um processo termina, 
mas em um sistema como o MINIX as interrupções devidas 
a operações de E/S ou ao relógio ocorrem mais freqüente- 
mente que o término de um processo. 0 agendador do MI- 
NTX utiliza um sistema de filas em três níveis, correspon¬ 
dentes às camadas 2, 3 e 4 da Figura 2-26. Dentro dos ní¬ 
veis de tarefa e de servidor, os processos executam até blo¬ 
quearem, mas os processos de usuário são agendados utili¬ 
zando round robin. As tarefas têm a prioridade mais alta, 
o gerenciador de memória e o servidor de arquivos vêm em 
seguida e, por último, os processos de usuário. 

Ao selecionar um processo para executar, o agendador 
verifica se qualquer tarefa está pronta. Se uma ou mais 
estiver pronta, a primeira da fila é executada. Se nenhuma 
tarefa estiver pronta, um servidor (FS ou MM) é escolhido, 
se possível; caso contrário um processo do usuário é execu¬ 
tado. Se nenhum processo estiver pronto, o processo IDLE é 
escolhido. Esse é um laço que executa até que a próxima 
interrupção ocorra. 

A cada tique do relógio, uma verificação é feita para ver 
se o processo atual é um processo de usuário que executou 
mais de lOOms. Se for, o agendador é chamado para ver se 
outro processo de usuário está esperando a CPU. Se algum 
for localizado, o processo atual é movido para o fim de sua 
fila de agendamento e o processo agora no topo é executa¬ 
do. As tarefas, o gerenciador de memória e o sistema de 
arquivos nunca sofrem preempção pelo relógio, indepen¬ 
dente de quanto tempo eles tenham estado executando. 

2.6 IMPLEMENTAÇÃO DE PROCESSOS 
EM MINIX 

Agora que estamos chegando mais perto do código real, 
são necessárias algumas palavras sobre a notação que uti¬ 


lizaremos. Os termos “procedimento", “função" e “roti¬ 
na” serão utilizados intercambiavelmente. Os nomes de 
variáveis, de procedimentos e de arquivos serão escritos em 
itálico, como em rwjlag. Quando uma variável, procedi¬ 
mento ou nome de arquivo inicia uma frase, ela ou ele é 
escrito com a primeira letra maiuscula, mas todos os no¬ 
mes começam com letras minúsculas. As chamadas de sis¬ 
tema estarão em caixa alta, por exemplo, READ. 

0 livro e o software, ambos os quais estão continua¬ 
mente desenvolvendo-se, não foram "para as máquinas” 
no mesmo dia; então, pode haver discrepâncias menores 
entre as referências ao código, à listagem impressa e à ver¬ 
são do CD-ROM. Essas diferenças, porém, geralmente só 
afetam uma linha ou duas. 0 código-fonte impresso no 
livro também foi simplificado para eliminar código utili¬ 
zado para compilar opções que não são discutidas no livro. 

2.6.1 Organização do Código-Fonte do 
MINIX 

Logicamente, o código-fonte é organizado como dois 
diretórios. Os caminhos completos para esses diretórios em 
um sistema MINIX padrão são /usr/include/ e /usr/src/ 
(uma barra, “/", ao final de um nome de caminho indica 
referência a um diretório). A localização real dos diretóri¬ 
os pode variar de sistema para sistema, mas normalmente 
a estrutura dos diretórios abaixo do nível mais alto será a 
mesma que em qualquer sistema. Neste texto, tais diretóri¬ 
os serão referidos como include/ e src/. 

O diretório include/ contém diversos arquivos de cabe¬ 
çalho do POSix padrão. Além disso, ele tem três subdiretó- 
rios: 

1. ígs/ - este subdiretório contém cabeçalhos adi¬ 

cionais do posix. 

2. minix/ - inclui arquivos de cabeçalho utilizados 

pelo sistema operacional. 

3. ibm/ - inclui arquivos de cabeçalho com defini¬ 

ções específicas do IBM PC. 

Para suportar extensões para o MINIX e programas que exe¬ 
cutam no ambiente MINIX, outros arquivos e subdiretórios 
também estão presentes em include/ como fornecido no 
CD-ROM ou na Internet. Por exemplo, o diretório include/ 
nel/ e seu subdiretório include/net/gen/ suportam exten¬ 
sões de rede. Entretanto, neste texto, apenas os arquivos 
necessários para compilar o sistema minix básico foram 
impressos e discutidos. 

0 diretório grc/ contém três subdiretórios importantes 
que contêm o código-fonte do sistema operacional: 

1. kemel/ - as camadas 1 e 2 (processos, mensagens e 

drivers) . 

2. mm/ - o código para o gerenciador de memória. 

3 ■ fs/ - o código para o sistema de arquivos. 

Há três outros diretórios de código-fonte que não são im¬ 
pressos nem discutidos no texto, mas que são essenciais 
para produzir um sistema funcional: 
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1. src/lib/ — o código-fonte para procedimentos de bi¬ 

blioteca (p. ex., open, read). 

2. src/tools/ - o código-fonte para o programa init. uti¬ 

lizado para iniciar o MIXIX. 

3. src/boot/ - o código para inicializar e instalar o 

MIXIX. 

A distribuição-padrão do minix inclui vários outros dire¬ 
tórios de fontes. Um sistema operacional existe, natural¬ 
mente, para suportar comandos (programas) que execu¬ 
tarão nele. Assim há um grande diretório src/command 
com o código-fonte para os programas utilitários (p. ex., 
cat. cp. date, ls. pwd) . Como o Mixix é um sistema opera¬ 
cional educacional, destinado a ser modificado, há um di- 
retório.sTc//a9//com programas projetados para testar com¬ 
pletamente um sistema recentemente compilado do MIXIX. 
Por fim, o diretório /src/inet/ inclui o código-fonte para 
recompilar o MINIX com suporte de rede. 

Por conveniência, normalmente iremos referir-nos a 
nomes simples de arquivo quando estiver claro a partir do 
contexto qual é o nome completo do caminho. Deve-se 
notar, entretanto, que alguns nomes de arquivo aparecem 
em mais de um diretório. Por exemplo, há vários arquivos 
chamados const.h em que constantes relevantes a uma 
determinada parte do sistema são definidas. Os arquivos 
em um diretório particular serão discutidos juntos, então, 
não deve haver nenhuma confusão. Os arquivos são rela¬ 
cionados no Apêndice A na ordem em que eles são discuti¬ 
dos no texto, para facilitar o acompanhamento. A utiliza¬ 
ção de um par de marcadores de página pode ser útil neste 
ponto. 

Também vale notar que o Apêndice B contém uma lista 
alfabética de todos os arquivos descritos no Apêndice A; e o 
Apêndice C contém uma lista de onde localizar as defini¬ 
ções de macros, de variáveis globais e de procedimentos 
utilizados no MINIX. 

0 código para as camadas 1 e 2 está contido no dire¬ 
tório src/kernel/. Neste capítulo, estudaremos os arquivos 
desse diretório que suportam o gerenciamento de proces¬ 
sos, a camada mais baixa da estrutura do minix que vimos 
na Figura 2-26. Essa camada inclui funções que gerenci¬ 
am a inicialização do sistema, interrupções, passagem de 
mensagens e agendamento de processos. No Capítulo 3, 
veremos os demais arquivos deste diretório, que suportam 
as várias tarefas, a segunda camada na Figura 2-26. No 
Capítulo 4, examinaremos os arquivos do gerenciador de 
memória em src/mm/ e no Capítulo 5, estudaremos o sis¬ 
tema de arquivos, cujos arquivos-fonte estão localizados 
em src/fs/. 

Quando o minix é compilado, todos os arquivos do có¬ 
digo-fonte em src/kernel/, src/mm/ e src/fs/ são compila¬ 
dos em arquivos-objeto. Todos os arquivos-objeto em src/ 
kernel/ estão vinculados para formar um único programa 
executável, kernel. Os arquivos-objeto em src/mm/ tam¬ 
bém estão vinculados para formar um único programa 
executável, mm. 0 mesmo se aplica a fs. As extensões po¬ 
dem ser aumentadas adicionando-se outros servidores. Por 


exemplo, suporte de rede é adicionado modificando-se in- 
clude/mínix/config.h a fim de ativar a compilação dos ar¬ 
quivos em src/we//para formar inet. Outro programa exe¬ 
cutável, init, está dentro de src/tools/. 0 programa install- 
boot (cujo fonte está em src/boot/) adiciona nomes a cada 
um desses programas, define que seu comprimento é um 
múltiplo do tamanho de setor de disco (para tornar mais 
fácil carregar as partes independentemente) e concatena- 
os em um único arquivo. Esse novo arquivo é o binário do 
sistema operacional e pode ser copiado para o diretório- 
raiz ou o diretório /minix/ de um disquete ou partição de 
disco rígido. Posteriormente, o programa monitor de inici¬ 
alização pode carregar e executar o sistema operacional. A 
Figura 2-27 mostra o arranjo da memória depois que os 
programas concatenados são separados e carregados. De¬ 
talhes, naturalmente, dependem da configuração do siste¬ 
ma. 0 exemplo na figura é para um sistema MINIX confi¬ 
gurado para tirar proveito de um computador equipado com 
vários megabytes de memória. Isso torna possível alocar 
um grande número de buffers do sistema de arquivos, mas 
o grande sistema de arquivos resultante não cabe no inter¬ 
valo mais baixo da memória, abaixo dos 640K. Se o núme¬ 
ro de buffers for reduzido drasticamente, é possível fazer 
todo o sistema caber em menos de 640K de memória, com 
espaço também para alguns processos de usuário. 

É importante saber que o MIXIX consiste em três ou mais 
programas totalmente independentes que se comunicam 
apenas passando mensagens. Um procedimento chamado 
panic em src/fs/ não gera conflito com um procedimento 
chamado panic em src/mm/ porque, em última instân¬ 
cia, eles estão vinculados* em arquivos executáveis dife¬ 
rentes. Os únicos procedimentos que as três partes do siste¬ 
ma operacional têm em comum são algumas das rotinas 
de biblioteca em lib/. Essa estrutura modular torna muito 
fácil modificar, digamos, o sistema de arquivos, sem que 
essas mudanças afetem o gerenciador de memória. Tam¬ 
bém toma simples remover o sistema de arquivos inteiro e 
colocá-lo em uma máquina diferente como um servidor 
de arquivos, para comunicar-se com máquinas de usuá¬ 
rios enviando mensagens por uma rede. 

Como outro exemplo da modularidade do minix, com¬ 
pilar o sistema com ou sem suporte de rede não faz absolu¬ 
tamente nenhuma diferença para o gerenciador de memó¬ 
ria ou para o sistema de arquivos e afeta o kernel só porque 
a tarefa de Ethernet está compilada ali, junto com o supor¬ 
te para outros dispositivos de E/S. Quando ativado, o servi¬ 
dor de rede é integrado ao sistema minix como um servidor 
com o mesmo nível de prioridade que o gerenciador de 
memória ou o servidor de arquivos. Sua operação pode 
envolver a transferência de grandes quantidades de dados 
muito rapidamente e isso requer prioridade mais alta do 
que um processo de usuário receberia. Exceto para a tarefa 
de Ethernet, entretanto, as funções de rede poderiam ser 


*N. de R. 0 termo original é linked, de link, que, neste contexto, é o 
processo de gerar um executável a partir de códigos-objeto compilados 
independentemente. 
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src/tools/init 
src/inet/inet (opcional) 

src/fs/fs 

src/mm/mm 


src/kernel/kernel 


Memória disponível 
para programas de 
usuário 

Init 

Tarefa de rede 


Sistema de arquivos 


Gerenciador de memória 

> s / / ' ? • ? / / / / ; ; s / / / / / ? s s / 

/ Memória apenas para í 
/ leitura e memória dos í 
' adaptadores de E/S (não- / 

' disponível para o MINIX / 

Memória disponível 
: : para programas de : : 
usuário 

Tarefa de Ethernet 
Tarefa de impressora 
Tarefa de terminal 
Tarefa de memória 
Tarefa de relógio 
Tarefa de disco 
Kernel 

lIllÈiiílll 

Vetor de interrupção 


O limite de memória 


2383 K 
2372 K 

2198 K (Depende do número de 

buffers incluídos no sistema 
de arquivos) 

1077 K 
1024 K 


640 K 


129 K (Depende do número de 
tarefas de E/S 


2 K Início do kernel 
1 K 
0 


Figura 2-27 0 arranjo de memória depois que o minix foi carregado a partir do disco para a memória. As 

quatro (ou cinco, incluindo o suporte de rede) partes compiladas e vinculadas independentemente são bem- 
distintas. Os tamanhos são aproximados, dependendo da configuração. 


executadas por processos no nível do usuário. As funções 
de rede não são funções tradicionais do sistema operacio¬ 
nal, e uma discussão detalhada do código de rede está além 
do escopo deste livro. Nas próximas seções e capítulos, a 
discussão será baseada em um sistema MINIX compilado 
sem suporte de rede. 

2.6.2 Os Arquivos de Cabeçalho Comuns 

0 diretório inclu.de/ e seus subdiretórios contêm uma 
coleção de arquivos definindo macros, constantes e tipos. 
0 padrão POSIX requer muitas dessas definições e especifi¬ 
ca em quais arquivos do diretório principal include/ e seu 
subdiretório include/sys/ será encontrada a definição ne¬ 
cessária. Os arquivos nesses diretórios são arquivos de 
cabeçalho {headerfiles), identificados pelo sufixo .h e uti¬ 
lizados por meio de declarações #include em arquivos-fonte 
em C. Essas declarações são um recurso da linguagem C. 


Os arquivos de cabeçalho tornam mais fácil a manutenção 
de um sistema grande. 

Os cabeçalhos provavelmente necessários para compi¬ 
lar programas de usuário estão localizados em include/ 
enquanto include/sys/ é tradicionalmente utilizado para 
arquivos que são utilizados principalmente para compilar 
programas de sistema e de utilitários. A distinção não é tão 
importante, e uma compilação típica, seja de um progra¬ 
ma de usuário ou de parte do sistema operacional, inclui¬ 
rá arquivos desses dois diretórios. Discutiremos aqui os ar¬ 
quivos que são necessários para compilar o sistema MlNix- 
padrão, primeiro tratando daqueles em include/ e, então, 
daqueles em include/sys/. Na próxima seção, discutiremos 
todos os arquivos nos diretórios include/minix/ e include/ 
IBM/, que, como os nomes de diretório indicam, são úni¬ 
cos para o MINIX e para sua implementação em computa¬ 
dores do tipo IBM. 
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Os primeiros cabeçalhos a serem considerados são ver¬ 
dadeiramente de propósito geral, tanto que eles não são 
referenciados diretamente por nenhum dos arquivos-fonte 
em linguagem C para o sistema minlx. Km vez disso, eles 
são incluídos em outros arquivos de cabeçalho, os cabeça¬ 
lhos-mestres src/kernel/kemel.b. src/mm/mm.h esrc/fs/ 
fs.b para cada uma das três partes principais do sistema 
MINIX, que, por sua vez, são incluídos em toda compilação. 
Cada cabeçalho-mestre é padronizado de acordo com as 
necessidades da parte correspondente do sistema MINIX, mas 
todos eles iniciam com uma seção como a mostrada na 
Figura 2-28. Os cabeçalhos-mestres serão discutidos nova¬ 
mente em outras seções do livro. Esta visualização prévia é 
para enfatizar que os cabeçalhos dos vários diretórios são 
utilizados juntos. Nesta seção e na próxima, mencionare¬ 
mos cada um dos arquivos referenciados na Figura 2-28. 

Iniciemos com o primeiro cabeçalho em include/, 
ansi.h (linha 0000). Este é o segundo cabeçalho que é pro¬ 
cessado sempre que qualquer parte do sistema mixix é com¬ 
pilada; só include/minix/config.h é processado antes. 0 
propósito de ansi.h é testar se o compilador satisfaz os re¬ 
quisitos do Standard C, como definidos pela International 
Organization for Standards. O Standard C também é cha¬ 
mado ANSI C, desde que o padrão originalmente foi desen¬ 
volvido pelo American National Standards Institute (ANSI) 
antes de ganhar reconhecimento internacional. Um com¬ 
pilador de Standard C define várias macros que, então, po¬ 
dem ser testadas na compilação de programas._ STDC_ 

_ é uma dessas macros e é definida por um compilador 
padrão para ter o valor de 1, como se o pré-processador de 
C lesse uma linha como 

#define_STDC_1 

O compilador distribuído com as versões atuais do MINIX é 
compatível com o Standard C, mas as versões mais antigas 
do MINIX foram desenvolvidas antes da adoção do padrão e 
ainda é possível compilar MINIX com um clássico (Kerni- 
ghan & Ritchie) compilador de C. A intenção é que o MINIX 
seja fácil de portar para novas máquinas, e permitir com¬ 
piladores mais antigos é parte disso. Nas linhas 0023 a 0025, 
a declaração 

#define ANSI 


é processada se um compilador Standard C estiver em uso. 
Ansi.h define várias macros de diferentes maneiras, depen¬ 
dendo de a macro _ANSI ser definida ou não. 

A macro mais importante neste arquivo é _PROTOTiTE. 
Essa macro permite escrever protótipos de função na for¬ 
ma 

_PROTOTYPE (tipo-de-retorno nome-da-função, 
(tipo-de-argumento argumento) ... 

e ter isso transformado pelo pré-processador de C em 

tipo-de-retorno nome-da-função (tipo-do-argumento 
argumento,) ... 

se o compilador seguir o padrão ANSI C, ou 

tipo-de-retorno nome-da-função () 

se o compilador for antigo (i. e., Kernighan & Ritchie). 

Antes de deixarmos ««x/Vz, permita-nos mencionar mais 
um recurso. O arquivo inteiro está incluído entre as linhas 

#ifndef _ANSI_H 

e 

#endif 

Na linha imediatamente seguinte ao #ifndef, o _ANS1_H 
em si é definido. Um arquivo de cabeçalho deve ser incluí¬ 
do só uma vez em uma compilação; essa construção asse¬ 
gura que o conteúdo do arquivo será ignorado se ele for 
incluído várias vezes. Veremos essa técnica utilizada em 
todos os arquivos de cabeçalho no diretório include/. 

O segundo arquivo em include/ que é indiretamente 
incluído em todos os arquivos-fonte do MINIX é o cabeça¬ 
lho limits.h (linha 0100). Esse arquivo define muitos ta¬ 
manhos básicos, sejam dos tipos de linguagem como o 
número de bits em um número inteiro, sejam os limites do 
sistema operacional como o comprimento do nome de um 
arquivo. Errno.h (linha 0200), também é incluído em to¬ 
dos os cabeçalhos-mestres. Ele contém os números de erro 
que são retornados para programas de usuário na variável 
global errno quando uma chamada de sistema falha. Err- 
no também é utilizado para identificar alguns erros inter¬ 
nos, como tentar enviar uma mensagem para uma tarefa 


#include <minix/config.h> /* DEVE ser o primeiro */ 

#include <ansi.h> /* DEVE ser o segundo */ 

#include <sys/types.h> 

#include <minix/const.h> 

#include <minix/type.h> 

#include <limits.h> 

#include <errno.h> 

#include <minix/syslib.h> 


Figura 2-28 Parte de um cabeçalho-mestre que assegura a inclusão de arquivos de cabeçalho 
necessários a todos os arquivos-fonte em C. 
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inexistente. Os números de erro são negativos para identi¬ 
ficá-los como códigos de erro dentro do sistema MINIX, mas 
devem ser tornados positivos antes de retomar aos progra¬ 
mas de usuário. O truque utilizado é que cada código de 
erro é definido em uma linha como 

#define EPERM (_SIGN 1) 

(linha 0236). O cabeçalho-mestre para cada parte do siste¬ 
ma operacional define a macro _SYSTEM, mas _SYSTEM 
nunca é definido quando um programa de usuário é com¬ 
pilado. Se _Si'STEM é definido, então _SIGNé definido como 
caso contrário recebe uma definição nula. 

O próximo grupo de arquivos a serem considerados não 
estão incluídos em todos os cabeçalhos-mestres, mas não 
obstante são utilizados em muitos arquivos-fonte em toda 
parte no sistema mintx. O mais importante é unistd.h (li¬ 
nha 0400). Esse cabeçalho define muitas constantes, a 
maioria das quais são requeridas pelo POSIX. Além disso, 
ele inclui protótipos para muitas funções do C, incluindo 
todas aquelas utilizadas para acessar chamadas de sistema 
MINTX. Outro arquivo amplamente utilizado éstring.h (li¬ 
nha 0600), que fornece protótipos para muitas funções de 
C utilizadas para gerenciamento de strings. O cabeçalho 
signal.b (linha 0700) define os nomes-padrão dos sinais. 
Também contém protótipos para algumas funções relati¬ 
vas a sinais. Como veremos mais adiante, a manipulação 
de sinais envolve todas as partes do MINTX. 

Fcntl.h (linha 0900) simbolicamente define muitos 
parâmetros utilizados em operações de controle de arqui¬ 
vo. Por exemplo, permite utilizar a macro ojrdonly em 
vez do valor numérico 0 como um parâmetro para uma 
chamada open. Embora esse arquivo seja referenciado, na 
maior parte, pelo sistema de arquivos, sutis definições tam¬ 
bém são necessárias em diversos lugares no kernel e no 
gerenciador de memória. 

Os demais arquivos em inclu.de/ não são tão ampla¬ 
mente utilizados como os já mencionados. Stdlib.b (linha 
1000) define tipos, macros e protótipos de função que pro¬ 
vavelmente serão necessários na compilação até do mais 
simples programa em C. É um dos cabeçalhos utilizados 
mais freqüentemente na compilação de programas de usu¬ 
ário, apesar de no fonte do sistema mintx ser referenciado 
apenas por alguns arquivos no kernel. 

Como veremos quando estudarmos a camada de tare¬ 
fas no Capítulo 3, o console e a interface de terminal de 
um sistema operacional são complexos, porque muitos ti¬ 
pos diferentes de hardware têm de interagir com o sistema 
operacional e com programas de usuário de uma maneira 
padronizada. O cabeçalho termios.h (linha 1100) define 
constantes, macros e protótipos de função utilizados para 
controle de dispositivos de E/S tipo terminal. A estrutura 
mais importante é a estrutura termios. Ela contém sinali¬ 
zadores para indicar vários modos de operação, variáveis 
para configurar velocidades de transmissão de entrada e 
de saída e uma matriz para armazenar caracteres espe¬ 
ciais, como os caracteres INTR e KILL. Essa estrutura é re¬ 


querida pelo POSIX, assim como o são muitas das macros e 
dos protótipos de função definidos neste arquivo. 

Entretanto, para ser tão abrangente como o padrão po- 
Six foi concebido para ser, ele não fornece tudo que se po¬ 
deria querer, e a última parte do arquivo, da linha 1241 em 
diante, fornece extensões para o POSIX. Algumas delas são 
de valor óbvio, como extensões para definir taxas-padrão 
de transmissão de dados de 57.600 baud e superiores, e 
suporte para exibição de janelas na tela do terminal. O pa¬ 
drão POSIX não proíbe extensões, já que nenhum padrão 
razoável poderia incluir tudo. Mas quando se escreve um 
programa no ambiente MINTX que se destina a ser portável 
para outros ambientes, alguma cautela é necessária para 
evitar o uso de definições específicas ao mintx. Isso é fácil 
de acontecer. Nesse e em outros arquivos que definem ex¬ 
tensões específicas do mintx, a utilização das extensões é 
controlada por uma declaração 

#ifdef MINIX 

Se _MMTnão for definido, o compilador nem mesmo verá 
as extensões do MINTX. 

0 último arquivo que consideraremos em include/ é 
a.out.b (linha 1400), um cabeçalho que define o formato 
dos arquivos em que os programas executáveis são arma¬ 
zenados em disco, incluindo a estrutura de cabeçalho uti¬ 
lizada para iniciar a execução de um arquivo e a estrutura 
da tabela de símbolos produzida pelo compilador. Ele é re¬ 
ferenciado só pelo sistema de arquivos. 

Agora vamos prosseguir para o subdiretório include/ 
sys/. Como mostrado na Figura 2-28, todos os cabeçalhos- 
mestres para as principais partes do sistema mintx incluem 
sys/types.h (linha l 600 ) imediatamente após ler ansi.h. 
Esse cabeçalho define muitos tipos de dados utilizados pelo 
MINTX. Os erros que poderiam surgir da má interpretação 
de quais tipos de dados fundamentais são utilizados em 
uma situação particular podem ser evitados, utilizando-se 
as definições fornecidas aqui. A Figura 2-29 mostra o modo 
como os tamanhos, em bits, de alguns tipos definidos neste 
arquivo diferem quando compilados para processadores de 
16 bits ou de 32 bits. Note que todos os nomes de tipo ter¬ 
minam com "_f. Isso não é só uma convenção; é um re¬ 
quisito do padrão POSIX. É um exemplo de um sufixo re¬ 
servado e não deve ser utilizado como um sufixo de qual¬ 
quer nome que não seja um nome de tipo. 

Embora não seja tão amplamente utilizado para ser 
incluído nos cabeçalhos-mestres de cada seção, sys/ioctl.h 
(linha 1800) define muitas macros utilizadas para opera¬ 
ções de controle de dispositivo. Ele também contém o pro¬ 
tótipo para a chamada de sistema IOCTL. Essa chamada 
não é diretamente invocada por programadores em mui¬ 
tos casos, uma vez que as funções definidas para o POSIX e 
as prototipadas em include/termios.h substituíram mui¬ 
tos antigos usos da antiga função de biblioteca ioctl para 
lidar com terminais, com consoles e com dispositivos se¬ 
melhantes. Mas ela ainda é necessária. De fato, as funções 
do POSIX para controle de dispositivos terminais são con- 
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Tipo 

MINIX de 16 bits 

MINIX de 32 bits 

gidj 

8 

8 

devj 

16 

16 

pidj 

16 

32 

inoj 

16 

32 


Figura 2-29. 0 tamanho, em bits, de alguns tipos em sistemas de 16 bits e de 32 bits. 


vertidas em chamadas de sistema IOCTL pela biblioteca. 
Além disso, há um número sempre crescente de dispositi¬ 
vos, todos os quais precisam de vários tipos de controle, 
que podem ser interfaceados com um moderno sistema de 
computador. Por exemplo, perto do fim deste arquivo estão 
várias definições de códigos de operação que começam com 
DSPIO, para controlar um processador digital de sinais. De 
fato, a diferença principal entre o minix como descrito nes¬ 
te livro e outras versões, é que para os propósitos do livro 
descrevemos um minix com relativamente poucos disposi¬ 
tivos de entrada/saída. Muitos outros, como interfaces de 
rede, unidades de CD-ROM e placas de som, podem ser adi¬ 
cionados; códigos de controle para todos esses são defini¬ 
dos como macros neste arquivo. 

Vários outros arquivos nesse diretório são amplamente 
utilizados no sistema do MINIX. 0 zrayÁvosys/sigcontext.h 
(linha 2000) define estruturas para conservar e para res¬ 
taurar a operação normal do sistema antes e depois da exe¬ 
cução de uma rotina de manipulaçao de sinal e é utilizado 
tanto no kernel como no gerenciador de memória. Há su¬ 
porte no MINIX para monitorar executáveis e analisar 
dumps de núcleo com um programa depurador, e sys/ 
ptrace.h (linha 2200) define as várias operações possíveis 
com a chamada de sistema PTRACK. Sys/stat.h (linha 2300) 
define a estrutura que vimos na Figura 1-12, retomada pelas 
chamadas de sistema stat e fstat. assim como os protóti¬ 
pos das funções stat e fstat e outras funções utilizadas para 
manipular propriedades de arquivos. Ele é referenciado em 
várias partes do sistema de arquivos e do gerenciador de 
memória. 

Os últimos dois arquivos que discutiremos nesta seção 
não são tão amplamente referenciados como os discutidos 
acima. Sys/dir.h (linha 2400) define a estrutura de uma 
entrada "de diretório do MINIX. É diretamente referenciado 
apenas uma vez, mas essa referência o inclui em outro ca¬ 
beçalho que é amplamente utilizado no sistema de arqui¬ 
vos. É importante porque, entre outras coisas, informa 
quantos caracteres um nome de arquivo pode conter. Por 
fim, o cabeçalho sys/wait.h (linha 2500) define macros 
utilizadas pelas chamadas de sistema wait e WAITPID, que 
são implementadas no gerenciador de memória. 


2.6.3 Arquivo de Cabeçalhos do MINIX 

Os subdiretórios indude/minix/ e indude/ibm/ con¬ 
têm arquivos de cabeçalho específicos do MINIX. Os arqui¬ 
vos em indude/minix1 são necessários para uma imple¬ 
mentação do MINIX em qualquer plataforma, embora haja 
definições alternativas específicas de plataforma dentro de 
alguns deles. Os arquivos em indude/ibm/ definem estru¬ 
turas e macros que são específicas do MINIX quando imple¬ 
mentado em máquinas tipo IBM. 

Iniciaremos com o diretório minix/. Na seção anterior, 
foi visto que config.h (linha 2600) é incluído nos cabeça¬ 
lhos-mestres por toda parte no sistema minix e, portanto, 
ele é o primeiro arquivo realmente processado pelo compi¬ 
lador. Em muitas ocasiões, quando diferenças no hardwa¬ 
re ou no modo como o sistema operacional destina-se a ser 
utilizado requerem mudanças na configuração do minix. 
Editar esse arquivo e recompilar o sistema é tudo o que 
deve ser feito. Todos os parâmetros configuráveis pelo usuá¬ 
rio estão na primeira parte do arquivo. O primeiro desses é 
o parâmetro MACHINE, que pode assumir valores como 
IBM_PC, SUN_4 , MACINTOSH ou outro valor, dependendo 
do tipo de máquina para o qual o MINIX está sendo compi¬ 
lado. A maior parte do código para o MINIX é independente 
do tipo de máquina, mas um sistema operacional sempre 
tem algum código dependente do sistema. Nos poucos lu¬ 
gares neste livro onde discutimos código que é escrito de 
maneira diferente para sistemas distintos, utilizaremos 
como exemplos o código para máquinas IBM PC com mi¬ 
croprocessadores avançados (80386,80486, Pentium, Pen¬ 
tium Pro) que utilizam palavras de 32 bits. Todos esses se¬ 
rão referidos como processadores Intel de 32 bits. O MINIX 
também pode ser compilado para IBM-PCs mais antigos 
com um tamanho de palavra de 16 bits. e as partes do Mi- 
XIX dependentes da máquina devem ser codificadas dife¬ 
rentemente para essas máquinas. Em um PC, o próprio 
compilador determina o tipo de máquina para a qual o 
MINIX será compilado. O compilador MINIX padrão para PC 
é o compilador Amsterdam Compiler Kit (ACK). Ele se iden¬ 
tifica definindo, além da macro _ STDC _, a macro _ 

_ACK_ _. Ele também define uma macro, _EM_WSIZE, 
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que é o tamanho de palavra (em bytes) para sua máquina 
de destino. Nas linhas 2626 a 2628, o valor de _EM_WSIZE 
é atribuído a macro _WORD_SIZE. Mais adiante no arqui¬ 
vo e em várias partes de outros arquivos-fonte minix, essas 
definições são utilizadas. Por exemplo, as linhas 2647 a 
265 O começam com 0 teste 

#if (MACHINE == IBM_PC && _WORD_SIZE == 4) 

e definem um tamanho para 0 cache do sistema de arqui¬ 
vos em sistemas de 32 bits. 

Outras definições em config.h permitem a personaliza¬ 
ção para outras necessidades em uma instalação particu¬ 
lar. Por exemplo, há uma seção que permite que vários ti¬ 
pos de drivers de dispositivo sejam incluídos quando 0 ker- 
nel do MINIX é compilado. Essa é provavelmente a parte 
mais freqüentemente editada do código-fonte do minix. Essa 
seção inicia com: 

#define ENABLE_NETWORKING 0 
#define ENABLE_AT_WINI 1 
#define ENABLE_BIOS_WINI 0 

Mudando 0 0 na primeira linha para 1 podemos compilar 
um kernel do MINIX para uma máquina que precisa supor¬ 
te de rede. Definindo ENABLE_AT_WINI como 0 e 
ENABLE_BIOS_WINl como 1, podemos eliminar 0 código 
do acionador de disco rígido tipo AT (i. e., IDE) e utilizar 0 
BIOS do PC para suporte de disco rígido. 

0 próximo arquivo é const.h (linha 2900 ), que ilustra 
outra utilização comum de arquivos de cabeçalho. Aqui 
encontraremos uma variedade de definições de constantes 
que provavelmente não serão alteradas quando se compi¬ 
lar um novo kernel, mas que são utilizadas em vários lu¬ 
gares. A definição delas aqui ajuda a prevenir erros que 
poderiam ser difíceis de monitorar se definições inconsis¬ 
tentes fossem feitas em múltiplos lugares. Há outros arqui¬ 
vos chamados const.h na árvore de fontes do minix, mas 
eles são de uso limitado. As definições utilizadas somente 
no kernel são incluídas em src/kernel/const.h. As defini¬ 
ções utilizadas apenas no sistema de arquivos são incluí¬ 
das em src/fs/const.h. 0 gerenciador de memória utiliza 
src/'mm/'const.h para suas definições locais. Só as defini¬ 
ções que são utilizadas em mais de uma parte do sistema 
MINIX são incluídas em include/minix/const.h. 

Algumas das definições em const.h são dignas de nota. 
EXTERN é definida como uma macro que se expande em 
extern (linha 2906). As variáveis globais que são declara¬ 
das em arquivos de cabeçalho e incluídas em dois ou mais 
arquivos são declaradas EXTERN, como em 

EXTERN int who; 

Se a variável for declarada apenas como 
int who; 

e incluída em dois ou mais arquivos, alguns linkeditors 
reclamariam de uma variável multiplamente definida. 
Além disso, 0 manual de referência de C (Kernighan e Ri- 
tchie, 1988) explicitamente proíbe tal construção. 


Para evitar esse problema, é necessário ter a declaração 
assim: 

extern int who; 

em todos os lugares, exceto um. Utilizando EXTERN, evita- 
se esse problema porque ela se expande em extern em todo 
lugar que const.h é incluída, exceto após uma redefinição 
explícita de EXTERN como uma string nula. Isso é feito 
em cada parte do MINIX, colocando-se definições globais 
em um arquivo especial chamado glo. h, por exemplo, src/ 
kernel/glo.h, que indiretamente é incluído em cada com¬ 
pilação. Dentro de cada glo.h há uma sequência 

#ifdef _TABLE 
#undef EXTERN 
#define EXTERN 
#endif 

e nos arquivos table.c de cada parte do minix há uma li¬ 
nha 

#define _TABLE 

precedendo a seção #include. Assim, quando os arquivos 
de cabeçalho são incluídos e expandidos como parte da 
compilação de table.c, extern não é inserida em qualquer 
lugar (porque EXTERN é definida como uma string nula 
dentro de table.c) e 0 armazenamento para as variáveis 
globais é reservado apenas em um lugar, no arquivo objeto 
table.o. 

Se você é iniciante em programação em C e não enten¬ 
de bem 0 que está ocorrendo aqui, não se apavore; os deta¬ 
lhes realmente não são importantes. A inclusão de múlti¬ 
plos arquivos de cabeçalho pode causar problemas para 
alguns linkeditors porque pode levar à múltiplas declara¬ 
ções para variáveis incluídas. O uso de EXTERN é simples¬ 
mente uma maneira de tornar 0 minix mais portável para 
que ele possa ser vinculado em máquinas cujos linkeditors 
não aceitam variáveis multiplamente definidas. 

PRTVATE é definido como um sinônimo de static. Os 
procedimentos e os dados que não são referenciados fora 
dos arquivos nos quais sempre são declarados como PRT 
VATE para evitar que seus nomes sejam visíveis de fora des¬ 
ses arquivos. Como regra geral, todas as variáveis e proce¬ 
dimentos devem ser declarados como de escopo local sem¬ 
pre que possível. PUBLIC é definida como string nula. As¬ 
sim, a declaração 

PUBLIC void free_zone(Dev_t dev, zone_t numb) 

sai do pré-processador do C como 

void free_zone(Dev_t dev, zone_t numb) 

que, de acordo com as regras de escopo de C, significa que 
0 nome free_zone é exportado do arquivo e pode ser utili¬ 
zado em outros arquivos. PRLVATE e PUBLIC não são ne¬ 
cessários, mas são tentativas de desfazer 0 dano causado 
pelas regras de escopo do C (0 padrão é os nomes serem 
exportados para fora do arquivo; deveria ser exatamente 0 
inverso). 
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0 resto de const.h define constantes numéricas utiliza¬ 
das por todo o sistema. Uma seção de const.h é dedicada a 
definições de máquina ou dependentes de configuração. 
Por exemplo, por todo o código-fonte, a unidade básica de 
tamanho de memória é o clique. 0 tamanho de um clique 
depende da arquitetura do processador, e as alternativas 
para arquiteturas Intel, Motorola 68000 e Sun SPARC são 
definidas nas linhas 2957 a 2965 . Esse arquivo também 
contém as macros MAX eMIN, assim podemos dizer 

z = MAX (x, y); 

para atribuir 0 maior de.r ey az. 

Type.h (linha 3100) é outro arquivo incluído em toda 
compilação por meio dos cabeçalhos-mestres. Ele contém 
um número de definições de tipos-chave, junto com os va¬ 
lores numéricos relacionados. A definição mais importan¬ 
te nesse arquivo é message nas linhas 3135 a 3146. Embo¬ 
ra pudéssemos ter definido message como sendo uma ma¬ 
triz de algum número de bytes, é melhor como prática de 
programação tê-la como uma estrutura contendo a união 
dos vários tipos de mensagem possíveis. Seis formatos de 
mensagem, mess_l a messjS, são definidos. Uma mensa¬ 
gem é uma estrutura que contém um campo m_source. 
informando quem enviou a mensagem, um campo m_ 
type, informando qual é 0 tipo da mensagem (p. ex., 
GETjtime para a tarefa de relógio) e os campos de dados. 
Os seis tipos de mensagem são mostrados na Figura 2-30, 
na qual, 0 primeiro e 0 segundo tipos de mensagem pare¬ 
cem idênticos, assim como 0 quarto e 0 sexto tipos. Isso é 
verdadeiro para 0 minix quando implementado em uma 
CPU Intel com um tamanho de palavra de 32 bits, mas 
não seria 0 caso em uma máquina onde os tipos int e lon- 
gs e ponteiros fossem de tamanhos diferentes. Definir seis 
formatos distintos torna mais fácil recompilar para uma 
arquitetura diferente. 

Quando é necessário enviar uma mensagem que con¬ 
tém, digamos, três inteiros e três ponteiros (ou três inteiros 
e dois ponteiros), então, 0 primeiro formato na Figura 2- 
30 é utilizado. O mesmo se aplica aos outros formatos. Como 
se atribui um valor ao primeiro número inteiro no primei¬ 
ro formato? Suponha que a mensagem chame-se x. Então, 
x.m_u refere-se à parte da união na estrutura da mensa¬ 
gem. Para referir-se à primeira das seis alternativas na 
união, utilizamos x.m_u.m_ml. Por fim, para chegar ao 
primeiro número inteiro nessa estrutura, usamos 
x.m_u.m_ml.mlil. Isso é bem-verboso, assim nomes de 
campo um pouco mais curtos são definidos como macros 
depois da definição de message em si. Assim x.ml_ll pode 
ser utilizado em vez d tx.m_u.m_ml. Todos nomes cur¬ 
tos têm a forma da letra m, 0 número do formato, um su¬ 
blinhado, uma ou duas letras que indicam se 0 campo é 
um inteiro, um ponteiro, um longo, um caractere, uma 
matriz de caracteres ou uma função e um número de se- 
qüência para distinguir múltiplas instâncias do mesmo tipo 
dentro de uma mensagem. 


A propósito, quando discutimos formatos de mensagem, 
é uma boa oportunidade para observar que um sistema ope¬ 
racional e seu compilador freqüentemente têm um “en¬ 
tendimento” sobre coisas como 0 arranjo das estruturas e 
isso pode tornar a vida do implementador mais fácil. No 
minix, os campos int em mensagens são, às vezes, utiliza¬ 
dos para armazenar tipos de dados unsigned. Em alguns 
casos, isso poderia causar overflow, mas 0 código foi escri¬ 
to utilizando 0 conhecimento de que 0 compilador do Mi- 
nix mapeia tipos unsigned para ints e vice-versa sem alte¬ 
rar os dados ou gerar código para detectar 0 overflow. Uma 
abordagem mais compulsiva seria substituir cada campo 
int por uma união de int e unsigned. O mesmo se aplica 
aos campos long nas mensagens; alguns deles podem ser 
utilizados para passar dados unsigned long. Estamos tra¬ 
paceando aqui? Talvez, alguém poderia dizer, mas se você 
deseja portar 0 MINIX para uma nova plataforma, evidente¬ 
mente, 0 formato exato das mensagens é algo em que você 
deve prestar muita atenção; e agora considere-se alertado 
sobre 0 fato de que 0 comportamento do compilador é ou¬ 
tro fator que precisa de atenção. 

Há um outro arquivo em include/minix que é univer¬ 
salmente utilizado, por meio da inclusão nos cabeçalhos 
mestres. Trata-se desyslib.h (linha 3300), que contém pro¬ 
tótipos para as funções de biblioteca de C chamadas a par¬ 
tir de dentro do sistema operacional para acessar outros 
serviços do sistema operacional. As bibliotecas de C não são 
discutidas em detalhe neste texto, mas muitas delas são 
padrão e estarão disponíveis em qualquer compilador C. 
Entretanto, as funções do C referenciadas por syslib.h são 
naturalmente bem-específicas para 0 minix, e portar 0 MI- 
nix para um novo sistema com um compilador diferente 
requer portar a maioria dessas funções de biblioteca. Feliz¬ 
mente, isso não é difícil, uma vez que essas funções sim¬ 
plesmente extraem os parâmetros da chamada de função e 
os inserem em uma estrutura de mensagem, depois envi¬ 
am a mensagem e extraem os resultados da mensagem de 
resposta. Muitas dessas funções de biblioteca são definidas 
em uma dúzia ou menos de linhas de código em C. 

Quando um processo precisa executar uma chamada 
de sistema do minix, ele envia uma mensagem para 0 ge¬ 
renciador de memória (MM para abreviar) ou 0 sistema de 
arquivos (FS para abreviar). Cada mensagem contém 0 
número da chamada de sistema desejada. Esses números 
são definidos no arquivo seguinte, callnr.h (linha 3400). 

O arquivo com.h (linha 3500) contém, principalmen¬ 
te, definições comuns utilizadas em mensagens do FS e do 
MM para as tarefas de E/S. Os números de tarefa também 
são definidos. Para diferenciar dos números de processo, 
os números de tarefa são negativos. Esse cabeçalho tam¬ 
bém define os tipos de mensagem (códigos de função) que 
podem ser enviados para cada tarefa. Por exemplo, a tarefa 
de relógio aceita códigos SET_ALARM (que é utilizado para 
configurar um temporizador) , CLOCKJTICK (quando uma 
interrupção de relógio ocorreu), GETJTIME (requisição da 
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Figura 2-30 Os seis tipos de mensagens utilizados no minix. 0 tamanho dos elementos de uma mensagem irão variar, dependendo 
da arquitetura da máquina: esse diagrama ilustra tamanhos em uma máquina com ponteiros de 32 bits, como o Pentium (Pro). 


hora atual) eSETJTIME (para configurar a hora atual). 0 
valor REALJÜME é o tipo de mensagem de resposta para a 
requisição GET_TIME. 

Por fim, include/minix/ contém vários cabeçalhos mais 
especializados. Entre esses estão boot.h (linha 3700), que é 
utilizado tanto pelo kernel como pelo sistema de arquivos 
para definir dispositivos e acessar parâmetros passados para 
o sistema pelo programa boot. Outro exemplo é ke)’tnap.h 
(linha 3800), que define as estruturas para implementar 
leiautes especializados de teclado para os conjuntos de ca¬ 
ractere requeridos por idiomas diferentes. Também é ne¬ 
cessário para programas que geram e carregam essas tabe¬ 
las. Alguns arquivos aqui, como partition.h (linha 4000), 
são utilizados só pelo kernel e não pelo sistema de arqui¬ 
vos nem pelo gerenciador de memória. Em uma imple¬ 
mentação com suporte para dispositivos adicionais de E/S, 


há mais arquivos de cabeçalho, para suportar outros dis¬ 
positivos. Sua colocação nesse diretório precisa de explica¬ 
ção. Idealmente, todos os programas de usuário acessariam 
dispositivos só pelo sistema operacional, e arquivos como 
esse seriam colocados em src/kernel/. Entretanto, a reali¬ 
dade do gerenciamento de sistema requer que haja alguns 
comandos de usuário que acessem as estruturas no nível 
de sistema, como os comandos para fazer partições de dis¬ 
co. É para suportar esses programas utilitários que esses 
arquivos de cabeçalho especializado são colocados na ár¬ 
vore de diretório indude/. 

0 último diretório de cabeçalho especializado que 
consideraremos, indude/ibm/, contém dois arquivos que 
fornecem definições relacionadas com família de compu¬ 
tadores IBM PC. Um desses é diskparm.h, que é necessário 
pela tarefa de disquete. Embora essa tarefa seja incluída 



88 TANENBAUM & WOODHULL 


na versão-padrão do MINIX, seu código-fonte não é discuti¬ 
do em detalhe nesse texto, uma vez que ele é muito seme¬ 
lhante à tarefa de disco rígido. 0 outro arquivo nesse dire¬ 
tório épartition.h (linha 4100), que define tabelas de par¬ 
tição de disco e constantes relacionadas utilizadas em sis¬ 
temas compatíveis com IBM-PC. Essas estão colocadas aqui 
para facilitar portar o minix para outra plataforma de har¬ 
dware. Para hardware diferente, indude/ibm/partition.b 
teria de ser substituído, presumivelmente por um partítion.h 
em outro diretório apropriadamente nomeado, mas a es¬ 
trutura definida no arquivo include/minix/partition.h é 
interna ao MINIX e deve permanecer inalterada em um MI- 
NIX hospedado em uma plataforma de hardware diferente. 

2.6.4 Estruturas de Dados de Processo 
e Arquivos de Cabeçalho 

Agora vamos aprofundar-nos e ver o que significa o có¬ 
digo em src/kemel/. Nas duas seções anteriores, estrutura¬ 
mos nossa discussão em torno de um trecho de um cabe¬ 
çalho-mestre típico; primeiro veremos o cabeçalho-mestre 
real para o kernel, kernel.h (linha 4200). Ele começa defi¬ 
nindo três macros. A primeira, _POSIX_SOURCE é uma ma¬ 
cro de teste de recurso definida pelo próprio padrão po- 
SIX. Exige-se que todas essas macros comecem com o ca¬ 
ractere de sublinhado, O efeito de definir a macro 
_POSLX_SOURCE é assegurar que todos os símbolos neces¬ 
sários pelo padrão e quaisquer outros explicitamente per¬ 
mitidos, mas não requeridos, sejam visíveis, enquanto ocul¬ 
ta quaisquer símbolos adicionais que são extensões não- 
oficiais ao POSIX. Já mencionamos as próximas duas defi¬ 
nições: a macro _MÍNDC anula o efeito de _POSIX_SOURCE 
para extensões definidas pelo MINIX, e _SYSTEM poder ser 
testada onde quer que seja importante fazer algo diferente 
ao compilar o código do sistema, em oposição ao código de 
usuário, como mudar o sinal dos códigos de erro. Kernel.h, 
então, inclui outros arquivos de cabeçalho a partir de in- 
clude/ e seus subdiretórios mdu.de/sys/ e indude/minix/. 
incluindo todos aqueles referenciados na Figura 2-28. Dis¬ 
cutimos todos esses arquivos nas duas seções anteriores. 
Por fim, quatro outros cabeçalhos do diretório local, src/ 
kernel/. são incluídos. 

Esse é um bom lugar para apontar para os iniciantes 
em linguagem C como os nomes de arquivo são citados em 
um declaração #include. Cada compilador C tem um dire¬ 
tório-padrão em que procura para incluir arquivos. Nor¬ 
malmente, est eé/usr/indude/. como ocorre em um siste¬ 
ma MINIX padrão. Quando o nome de um arquivo a ser 
incluído é citado entre os símbolos ‘menor que' e ‘maior 
que’ (“< o compilador procura o arquivo no dire¬ 

tório include-padrão ou em um subdiretório específico do 
padrão. Quando o nome é citado entre aspas normais (“ 
o arquivo éprocurado primeiro no diretório atu¬ 
al (ou em um subdiretório especificado) e, então, se não 
estiver localizado ali, no diretório padrão. 


Kernel.h torna possível garantir que todos os arquivos- 
fonte compartilhem um grande número de definições im¬ 
portantes escrevendo a simples linha 

#include “kernel.h” 

em cada um dos outros arquivos-fonte do kernel. Como, às 
vezes, é importante a ordem de inclusão dos arquivos de 
cabeçalho, kernel.h também assegura que essa ordem seja 
feita corretamente uma vez e para sempre. Isso carrega para 
um nível mais alto a técnica “faça certo uma vez e, então, 
esqueça os detalhes" incorporada no conceito de arquivo 
de cabeçalho. Há cabeçalhos-mestres semelhantes nos di¬ 
retórios de fontes do sistema de arquivos e do gerenciador 
de memória. 

Agora passemos a examinar os quatro arquivos de ca¬ 
beçalho locais incluídos em kernel.h. Assim como temos 
arquivos const.h e type.h no diretório de cabeçalho comum 
indude/minix/. também temos arquivos const.h. e type.h 
no diretório-fonte do kernel, src/kemel/. Os arquivos em 
indude/minix/ estão colocados aí porque são necessários 
para muitas partes do sistema, incluindo programas que 
executam sob o controle do sistema. Os arquivos em src/ 
kernel/ fornecem definições necessárias só para a compi¬ 
lação do kernel. Os diretórios-fonte do FS e do MM tam¬ 
bém contêm arquivos const.h e type.h para definir cons¬ 
tantes e tipos necessários só para essas partes do sistema. 
Os outros dois arquivos incluídos no cabeçalho-mestre. 
pro/o.heglo.h. não têm correspondentes nos diretórios prin¬ 
cipais de include/, mas veremos que eles, também, têm 
correspondentes utilizados na compilação do sistema de 
arquivos e do gerenciador de memória. 

Const.h (linha 4300) contém alguns valores dependen¬ 
tes de máquina, isto é, valores que se aplicam aos chips de 
CPU da Intel, mas que provavelmente são diferentes quan¬ 
do o UNIX é compilado para hardware diferente. Esses valo¬ 
res são incluídos entre as declarações 

#jf (CHIP == INTEL) 

e 

#endif 

(linhas 4302 até 4396) para agrupá-los. 

Ao compilar o minix para um chip Intel as macros CHIP 
e INIEL são definidas e configuradas iguais em include/ 
minix/config.h (linha 2768), e assim o código dependente 
de máquina será compilado. Quando o minix foi portado 
para um sistema baseado no Motorola 68000, as pessoas 
que fizeram essa portagem adicionaram seções de código 
agrupadas por 

#if (CHIP == M68000) 

e 

#endif 
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e fizeram mudanças apropriadas em include/minix/ 
config.h para que a linha 

#define CHIP M68000 

fosse efetiva. Dessa maneira, o mixix pode lidar com códi¬ 
go e constantes que são específicos de um sistema. Essa 
construção não aumenta especialmente a legibilidade, en¬ 
tão, deve ser utilizada o mínimo possível. De fato, em favor 
da legibilidade, removemos muitas seções do código de¬ 
pendentes de máquina, para o 68000 e para outros proces¬ 
sadores da versão do código impresso neste texto. O código 
distribuído no CD-ROM e pela Internet mantém o suporte 
para outras plataformas. 

Algumas das definições em const.h merecem menção 
especial. Algumas delas são dependentes de máquina, como 
importantes vetores de interrupção e de valores de campo 
utilizados para reinicializar o chip controlador de inter¬ 
rupções após cada interrupção. Cada tarefa dentro do ker¬ 
nel tem sua própria pilha, mas no gerenciamento de inter¬ 
rupções é utilizada uma pilha especial do tamanho de 
K_STACK_BYiES. definido aqui na linha 4304. Isso tam¬ 
bém é definido dentro da seção dependente de máquina, 
uma vez que uma arquitetura diferente poderia requerer 
mais ou menos espaço de pilha. 

Outras definições são independentes de máquina, mas 
necessárias para muitas partes do código do kernel. Por 
exemplo, o agendador do MINIX tem NQ (3) filas de priori¬ 
dade, chamadas TASK_Q (prioridade úXíi) ,SER\RR_Q (pri¬ 
oridade média) e USER _Q (prioridade baixa). Os nomes 
são utilizados para fazer o código-fonte compreensível, mas 
é o valor numérico definido por essas macros que realmente 
é compilado no programa executável. Por fim, a última 
linha de const.h define printf c omo uma macro que será 
traduzida como printk. Isso permite que o kernel imprima 
mensagens no console, como mensagens de erro, utilizan¬ 
do um procedimento definido dentro do kernel. Esse é um 
desvio do mecanismo normal, que requer passar mensa¬ 
gens do kernel para o sistema de arquivos, e então do siste¬ 
ma de arquivos para a tarefa de impressora. Durante uma 
falha de sistema isso pode não funcionar. Veremos chama¬ 
das para printf aliás printk, em uma chamada de procedi¬ 
mento do kernel chamada/w«'c que, como se poderia es¬ 
perar, é invocada quando erros fatais são detectados. 

O arquivo type.h (linha 4500) define vários protótipos 
e estruturas utilizadas em qualquer implementação do MI- 
XIX. A estrutura tasktab define a estrutura de um elemento 
da matriz tasktab, e a estrutura memory (linhas 4513 a 
4516) define as duas quantidades que singularmente espe¬ 
cificam uma área da memória. Eis um bom lugar para 
mencionar alguns conceitos utilizados em referência à me¬ 
mória. Um click é a unidade básica de medida de memó¬ 
ria; no MINIX para processadores Intel, um click equivale a 
256 bytes. A memória é medida como pbysjdicks, que pode 
ser utilizada pelo kernel para acessar qualquer elemento 
da memória em qualquer lugar no sistema, ou como 
vir_clicks, utilizada por processos outros que não o kernel. 
Uma referência de memória virjdicks é sempre com rela¬ 


ção à base de um segmento de memória atribuído a um 
processo particular, e o kernel frequentemente tem de fa¬ 
zer traduções entre os dois. A inconveniência disso é com¬ 
pensada pelo fato de que um processo pode fazer todas as 
suas próprias referências de memória em vir_dicks. Al¬ 
guém poderia supor que a mesma unidade poderia ser uti¬ 
lizada para especificar o tamanho de qualquer tipo de me¬ 
mória, mas há uma vantagem em utilizar virjdicks para 
especificar o tamanho de uma unidade de memória atri¬ 
buída a um processo, uma vez que, quando essa unidade é 
utilizada, uma verificação é feita para assegurar que ne¬ 
nhuma memória seja acessada fora do que foi especifica¬ 
mente atribuído ao processo atual. Esse é um recurso im¬ 
portante do modo protegido dos processadores Intel mo¬ 
dernos, como o Pentium e o Pentium Pro. Sua ausência 
nos processadores anteriores 8086 e 8088 causou algumas 
dores de cabeça no projeto das primeiras versões do MINIX. 

Type.h também contém várias definições de tipos de¬ 
pendentes de máquina, como port_t,segm_t e regj (li¬ 
nhas 4525 a 4527) utilizados em processadores Intel, para, 
respectivamente, endereçar portas de E/S. segmentos de 
memória e registradores de CPU. 

As estruturas, também, podem ser dependentes de má¬ 
quina. Nas linhas 4537 a 4558, a estrutura stackframe_s. 
que define como os registradores de máquina são salvos na 
pilha, é definida para processadores Intel. Essa estrutura é 
extremamente importante — ela é utilizada para salvar e 
para restaurar o estado interno da CPU sempre que um 
processo é colocado ou removido do estado "em execução" 
da Figura 2-2. Definindo-o de uma forma que possa efeti¬ 
vamente ser lida ou escrita por código em linguagem as¬ 
sem bly. reduz-se o tempo necessário para uma comutação 
de contexto. Segdesc_s é outra estrutura relacionada com 
a arquitetura dos processadores Intel. É parte do mecanis¬ 
mo de proteção que impede que os processos acessem regi¬ 
ões de memória fora daquelas atribuídas a eles. 

Para ilustrar diferenças entre plataformas, algumas 
definições para a família de processadores Motorola 68000 
foram mantidas nesse arquivo. A família de processadores 
Intel inclui alguns modelos com registradores de l6 bits e 
outros com registradores de 32 bits, portanto, o tipo regj 
básico é unsigned para a arquitetura Intel. Para processa¬ 
dores Motorola, regj é definido como o tipo u32_t. Esses 
processadores também precisam de uma estrutura 
stackframe_s (linhas 4583 a 4603), mas o leiaute é dife¬ 
rente, para tornar as operações de código assembly que a 
utilizam mais rápidas. A arquitetura Motorola não tem 
nenhuma necessidade dos tipos portj e segrnj, ou da es¬ 
trutura segdesc_s. Também há várias estruturas definidas 
para a arquitetura Motorola que não têm nenhum corres¬ 
pondente Intel. 

O próximo arquivo .proto.h (linha 4700), é o mais lon¬ 
go arquivo de cabeçalho que veremos. Os protótipos de to¬ 
das as funções que devem ser conhecidas fora do arquivo 
em que são definidas estão nesse arquivo. Todos são escri¬ 
tos utilizando a macro _PROTOTYPE discutida na seção 
anterior e, assim, o kernel do MINIX pode ser compilado 
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com um compilador C clássico (Kemighan e Ritchie), como 
o compilador C original do MiNix, ou com um moderno 
compilador ANSI Standard C, como o que é parte da versão 
2 do MiNix. Alguns desses protótipos são dependentes de sis¬ 
tema, incluindo manipuladores de interrupções e de exce¬ 
ções, e de funções escritas em linguagem assembly. Os pro¬ 
tótipos de funções necessárias para drivers não-discutidos 
neste texto não são mostrados. 0 código condicional para 
processadores Motorola também foi excluído deste e dos 
demais arquivos que discutiremos. 

0 último dos cabeçalhos do kernel incluídos no cabe¬ 
çalho mestre églo.h (linha 5000). Encontraremos aqui as 
variáveis globais do kernel. O propósito da macro EXTERN 
foi descrito na discussão sobre include/minix/const.h. Nor¬ 
malmente ela se expande em extern. Note que muitas defi¬ 
nições em glo.h são precedidas por essa macro. EXTERN é 
forçado a ser não-definido quando esse arquivo é incluído 
em table.c, onde a macro JTABLE é definida. Incluindo 
glo.h em outros arquivos-fonte de C, tornamos as variáveis 
em table.c conhecidas para os outros módulos no kernel. 
Held_head e held_tail (linhas 5013 e 5014) são ponteiros 
para uma fila de interrupções pendentes. Proc_ptr (linha 
5018) aponta para a entrada na tabela de processos para o 
processo atual. Quando uma chamada de sistema ou uma 
interrupção ocorre, ele informa onde armazenar os regis¬ 
tradores e o estado do processador. Sig_procs (linha 5021) 
informa o número de processos que têm sinais pendentes 
que ainda não foram enviados ao gerenciador de memória 
para processamento. Alguns itens em glo.h são definidos 
com extern em vez de EXTERN. Esses incluem sizes, uma 
matriz preenchida pelo monitor de inicialização, a tabela 
de tarefas, tasktab, e a pilha de tarefas, t_stack. Os dois 
últimos são variáveis inicializadas, um recurso da lin¬ 
guagem C. A utilização da macro EXIERN não é compatí¬ 
vel com inicialização no estilo C, já que uma variável só 
pode ser inicializada uma vez. 

Cada tarefa tem sua própria pilha dentro de t_stack. 
Durante a manipulação de interrupções, o kernel utiliza 
uma pilha separada, mas ela não é declarada aqui, uma 
vez que só é acessada pela rotina no nível da linguagem 
assembly que gerencia o processamento de interrupções e 
não precisa ser conhecida globalmente. 

Há mais dois arquivos de cabeçalho do kernel que são 
amplamente utilizados, embora não tanto para serem in¬ 
cluídos em kernel. O primeiro deles éproc. h (linha 5100), 
que define uma entrada de tabela de processos como a es- 
trutura/irac (linhas 5110 a 5148). Mais adiante, no mes¬ 
mo arquivo, ele define a própria tabela de processos como 
uma matriz dessas estruturas, proc[NR_TASKS + NR_ 
PROCS] (linha 5186). Na linguagem C, essa reutilização 
de um nome é permitida. A macro NR_TASKS é definida 
em include/minix/const.h (linha 2953) e NR PROCS é 
definida em include/minix/config.h (linha 2639) ■ Juntas, 
tais macros configuram o tamanho da tabela de processos. 
NR_PROCS poder ser alterada para criar um sistema ca¬ 
paz de gerenciar um número maior de usuários. Como a 
tabela de processos é acessada freqüentemente, e calcular 


um endereço em uma matriz requer lentas operações de 
multiplicação, uma matriz de ponteiros para os elementos 
da tabela de processos, pproc_addr (linha 5187), é utili¬ 
zada para permitir acesso rápido. 

Cada entrada da tabela contém o espaço de armazena¬ 
mento para os registradores, para o ponteiro de pilha, para 
o estado, para o mapa de memória, para o limite da pilha, 
para o id, para a contabilidade, para o tempo do alarme e 
para informações de mensagens do processo. A primeira par¬ 
te de cada entrada da tabela de processo é uma estrutura 
stackframe_s. Um processo é colocado em execução carre¬ 
gando em seu ponteiro de pilha o endereço da sua entrada 
na tabela de processos e lendo todos os registradores da CPU 
a partir dessa estrutura. Quando um processo não pode com¬ 
pletar um send porque o destino não está esperando, o re¬ 
metente é colocado em uma fila apontada pelo campo 
p_callerq do destino (linha 5137). Dessa maneira, quando 
o destino por fim faz um receive, é fácil localizar todos os 
processos que querem enviar para ele. O campo pjsendlink 
(linha 5138) é utilizado para agrupar os membros da fila. 

Quando um processo faz um receive e não há nenhu¬ 
ma mensagem esperando por ele, ele bloqueia, e o número 
do processo de quem ele quer receber é armazenado em 
p_getfrom. O endereço do buffer de mensagem é armaze¬ 
nado em p_messbuf. Os últimos três campos em cada en¬ 
trada da tabela de processo são p_nextready, p Jtending e 
p_j>endcount (linhas 5143 a 5145). O primeiro desses é 
utilizado para agrupar os processos nas filas do agendador, 
enquanto o segundo é um mapa de bits utilizado para 
monitorar sinais que ainda não foram passados para o ge¬ 
renciador de memória (porque o gerenciador de memória 
não está esperando uma mensagem). 0 último campo é 
uma contabilização desses sinais. 

Os bits de sinalizador em p Jlags definem o estado de 
cada entrada da tabela. Se qualquer um dos bits está liga¬ 
do, o processo não pode ser executado. Os vários sinaliza¬ 
dores são definidos e descritos nas linhas 5154 a 5160. Se a 
entrada não está em uso, P_SLOT_FREE é ligado. Após um 
FORK, NO_MAP é ligado para evitar que o processo-filho 
execute até que seu mapa de memória tenha sido definido. 
INSENDING e RECEMNG indicam que o processo está blo¬ 
queado tentando enviar ou receber uma mensagem. PEN- 
DING e SIG_PENDING indicam que sinais foram recebi¬ 
dos e PJSTOP fornece suporte para monitoramento, du¬ 
rante a depuração. 

A macro proc_addr (linha 5179) é fornecida porque 
não é possível ter subscritos negativos em C. Logicamente, 
a matriz proc deveria ir de -NR_TASKS a +NR_PROCS. 
Infelizmente, em C, ela deve iniciar em 0, portanto, proc[0] 
refere-se à tarefa mais negativa e assim por diante. Para 
tornar mais fácil monitorar qual entrada acompanha qual 
processo, podemos escrever 

rp = proc_addr(n); 

para atribuir a rp o endereço da entrada de processo para o 
processo n, seja ele positivo ou negativo. 
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Bill_ptr (linha 5191) aponta para o processo que está 
sendo cobrado pela CPU. Quando um processo de usuário 
chama o sistema de arquivos e o sistema de arquivos está 
executando, proc_ptr (em glo.h) aponta para o processo 
do sistema de arquivos. Entretanto, bill_ptr apontará para 
o usuário que está fazendo a chamada, já que o tempo de 
CPU utilizado pelo sistema de arquivos é contabilizado 
como tempo de sistema para o processo que fez a chama¬ 
da. 

As duas matrizes rdyjiead e rdyjail são utilizadas 
para manter as filas de agendamento. 0 primeiro processo 
na fila de tarefas, por exemplo, é apontado por rdy_ 
head[TASK_Q\. 

Outro cabeçalho que é incluído em diversos arquivos- 
fonte éprotect.h (linha 5200). Quase tudo nesse arquivo 
trata de detalhes de arquitetura dos processadores Intel que 
suportam o modo protegido (os 80286, 80386,80486, Pen¬ 
tium e Pentium Pro). Uma descrição detalhada desses chips 
está ale'm do escopo deste livro. É suficiente dizer que eles 
contêm registradores internos que apontam para tabelas 
descritoras na memória. As tabelas descritoras definem 
como os recursos de sistema são utilizados e evitam que os 
processos acessem a memória atribuída a outro processo. 
Além disso, a arquitetura do processador oferece quatro 
níveis de privilégio, dos quais o MINIX tira proveito de 
três. Esses são definidos simbolicamente nas linhas 5243 a 
5245. As partes mais centrais do kernel, as partes que exe¬ 
cutam durante interrupções e que alternam processos, exe¬ 
cutam com INTR_PRMLEGE. Não há nenhuma parte da 
memória ou registrador da CPU que não possa ser acessa¬ 
do por um processo com esse nível de privilégio. As tarefas 
executam no nível TASK_PRP/1LEGE, que as permite aces¬ 
sar E/S, mas não utilizar instruções que modificam regis¬ 
tradores especiais, como aqueles que apontam para tabe¬ 
las descritoras. Os processos de servidor e de usuário exe¬ 
cutam no nível USER_PRl\ r ILEGE. Os processos que exe¬ 
cutam nesse nível são incapazes de executar certas instru¬ 
ções, por exemplo aquelas que acessam portas de E/S, alte¬ 
ram atribuições de memória ou alteram os próprios níveis 
de privilégio. O conceito de níveis de privilégio será famili¬ 
ar para aqueles que conhecem a arquitetura das CPUs 
modernas, mas aqueles que aprenderam arquitetura de 
computadores estudando a linguagem assembly de micro¬ 
processadores baratos podem não ter encontrado essas res¬ 
trições. 

Há vários outros arquivos de cabeçalho no diretório do 
kernel, mas mencionaremos aqui só mais dois. Primeiro, 
h ásconst.h (linha 5400), que contém constantes utiliza¬ 
das pelo código tzssembler. Todas essas são deslocamentos 
(offsets ) na parte stackfmme_s da estrutura de uma en¬ 
trada na tabela de processo, expressa de uma forma utili¬ 
zável pelo assembler. Como o código assembler não é pro¬ 
cessado pelo compilador C, é mais simples ter essas defini¬ 
ções em um arquivo separado. Além disso, como todas es¬ 
sas definições são dependentes de máquina, isolá-las aqui 
simplifica o processo de portar o MIMX para outro proces¬ 
sador que precisará de uma versão diferente de sconst.h. 


Note que muitos deslocamentos são expressos como o va¬ 
lor anterior mais W, que é definido como igual ao tama¬ 
nho de palavra na linha 5401. Isso permite que o mesmo 
arquivo sirva para compilar uma versão de 16 ou de 32 bits 
do MINIX. 

Há um problema em potencial aqui. Os arquivos de 
cabeçalho destinam-se a permitir que se forneça um único 
conjunto correto de definições e então utilizá-las em mui¬ 
tos lugares sem prestar mais atenção aos detalhes. Obvia¬ 
mente, definições duplicadas, como aquelas em sconst.h. 
violam esse princípio. Isso é um caso especial, naturalmen¬ 
te, mas, como tal, atenção especial é requerida se forem 
feitas mudanças nesse arquivo ou em proc. h, para assegu¬ 
rar que os dois arquivos sejam consistentes. 

O cabeçalho final que mencionaremos aqui é assert.h 
(linha 5500). O padrão POSix requer a disponibilidade de 
uma função assert, que pode ser utilizada para fazer um 
teste em tempo de execução e abortar um programa, im¬ 
primindo uma mensagem. De fato, o posix requer que um 
cabeçalho assert.h seja fornecido no diretório include/, e 
um é fornecido lá. Então, por que há outra versão aqui? A 
resposta é que quando algo dá errado em um processo de 
usuário, pode-se contar com o sistema operacional para 
fornecer serviços como imprimir uma mensagem no con¬ 
sole. Mas se algo dá errado no próprio kernel, não se pode 
contar com os recursos normais do sistema. O kernel, as¬ 
sim, oferece suas próprias rotinas para gerenciar assert e 
imprimir mensagens, independentemente das versões na 
biblioteca normal do sistema. 

Há alguns arquivos de cabeçalho em kernel/ que ainda 
não discutimos. Eles suportam as tarefas de E/S e serão 
descritos no próximo capítulo, onde são relevantes. Antes 
de passar para o código executável, entretanto, vejamos 
table.c (linha 5600), cujo arquivo objeto compilado con¬ 
tém todas as estruturas de dados do kernel. Já vimos mui¬ 
tas dessas estruturas de dados definidas, em glo.h eproc.h. 
Na linha 5625, a macro _TABLE é definida, imediatamen¬ 
te antes das declarações #include. Como é explicado, essa 
definição faz com que EXTERN tome-se definida como uma 
string nula e o espaço de armazenamento seja atribuído a 
todas as declarações de dados precedidas EXTERN. Além 
das estruturas em glo.h eproc.h, o armazenamento para 
algumas variáveis globais utilizadas pela tarefa de termi¬ 
nal. definidas em tty.h, também estão alocadas aqui. 

Além das variáveis declaradas em arquivos de cabeça¬ 
lho, há dois outros lugares onde o armazenamento global 
de dados é alocado. Algumas definições são feitas direta¬ 
mente em table.c. Nas linhas 5639 a 5674, o espaço de pi¬ 
lha é alocado para cada tarefa. Para cada tarefa opcional, 
a macro ENABLE_XXX correspondente (definida no arqui¬ 
vo include/minix/config.h) é utilizada para calcular o ta¬ 
manho da pilha. Portanto, nenhum espaço é alocado para 
uma tarefa que não esteja ativa. Seguindo isso, as várias 
macros ENABLE_XXX são utilizadas para determinar se 
cada tarefa opcional será representada na matriz tasktab, 
composta pelas estruturas tasktab, como declaradas ante¬ 
riormente em src/kernel/type.h (linhas 5699 a 5731). Há 
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um elemento para cada processo que é iniciado durante a 
inicialização de sistema, seja ele um processo de tarefa, 
um processo de servidor ou um processo de usuário (i. e., 
init). 0 índice da matriz implicitamente mapeia entre os 
números de tarefa e os procedimentos de inicialização as¬ 
sociados. Tasktab também especifica o espaço de pilha ne¬ 
cessário para cada processo e fornece umastring de identi¬ 
ficação para cada processo. Ele foi colocado aqui em vez 
de em um arquivo de cabeçalho porque o truque com EX¬ 
TERN, utilizado para impedir múltiplas declarações, não 
funciona com variáveis inicializadas; isto é, você não pode 
dizer 

extern int x = 3; 

em qualquer lugar. As definições anteriores de tamanho de 
pilha também permitem alocação de espaço de pilha para 
todas as tarefas na linha 5734. 

Apesar de tentar isolar todas as informações de confi¬ 
guração definíveis pelo usuário em include/minix/ 
config.h. é possível ocorrer um erro ao fazer-se coincidir o 
tamanho da matriz tasktab com NR_TASKS. No fim de 
table.c, um teste é feito para esse erro, utilizando um pe¬ 
queno truque. A matriz dummyjasktab é declarada aqui 
de tal maneira que seu tamanho será impossível e desen¬ 
cadeará um erro de compilador se um engano for feito. 
Uma vez que a matriz [dummy] é declarada como extern, 
nenhum espaço é alocado para ela aqui (ou em qualquer 
lugar). Como ela não é referenciada em qualquer outro 
lugar no código, isso não perturbará o compilador. 

O outro lugar onde o armazenamento global é alocado 
está no fim do arquivo de linguagem assembly mpx386.s 
(linha 6483). Essa alocação, sob o rótulo _sizes, coloca 
um número mágico (para identificar um kernel MINIX vá¬ 
lido) bem no começo do segmento de dados do kernel. Es¬ 
paço adicional está alocado aqui pela pseudo-instrução 
.space. A reserva de espaço de armazenamento dessa ma¬ 
neira pelo programa de linguagem assembly torna possí¬ 
vel forçar a matriz _sizes a localizar-se fisicamente no co¬ 
meço do segmento de dados do kernel, tornando fácil pro¬ 
gramar boot para colocar os dados no lugar correto. 0 mo¬ 
nitor de inicialização lê o número mágico e, se estiver cor¬ 
reto, sobrescreve-o para iniciar a matriz _sizes com os ta¬ 
manhos das diferentes partes do sistema MINIX. 0 kernel 
utiliza esses dados durante a inicialização. No momento 
da inicialização, no que diz respeito ao kernel, essa é uma 
área de dados inicializada. Entretanto, os dados que o ker¬ 
nel acaba encontrando não estão disponíveis no momento 
da compilação. Ele são atualizados pelo monitor de inicia¬ 
lização logo antes de o kernel ser inicializado. Isso é algo 
incomum, normalmente não é necessário escrever progra¬ 
mas que conhecem a estrutura interna de outro programa. 
Mas o período de tempo depois que a energia é aplicada, 
mas antes de o sistema operacional começar a executar, é 
incomum e requer técnicas incomuns. 


2.6.5 Fazendo a Inicialização 
do MINIX 

Já é quase hora de começar a examinar o código exe¬ 
cutável. Mas antes de fazer isso, dedicaremos alguns mi¬ 
nutos para entender como MINIX é carregado na memória. 
Ele é, naturalmente, carregado a partir de um disco. A Fi¬ 
gura 2-31 mostra como disquetes e discos particionados 
são organizados. 

Quando o sistema é iniciado, o hardware (na realida¬ 
de, um programa na ROM) lê o primeiro setor do disco de 
boot e executa o código aí localizado. Em um disquete de 
MINIX não-particionado, o primeiro setor é um bloco de 
boot que carrega o programa de boot, como na Figura 2- 
31 (a). Os discos rígidos são particionados, e o programa 
no primeiro setor lê a tabela de partição, que também está 
no primeiro setor e carrega e executa o primeiro setor da 
partição ativa, como mostrado na Figura 2-31 (b) (Normal¬ 
mente uma e apenas uma partição é marcada como ati¬ 
va). Uma partição do MINIX tem a mesma estrutura que 
um disquete de MINIX não-particionado, com um bloco de 
boot que carrega o programa de boot. 

A situação real pode ser um pouco mais complicada do 
que aquela que a figura mostra porque uma partição pode 
conter subpartições. Nesse caso, o primeiro setor da parti¬ 
ção será outro registro-mestre de inicialização contendo a 
tabela de partição para as subpartições. Mas, enfim, o con¬ 
trole será passado a um setor de boot. o primeiro setor em 
um dispositivo que não é subdividido ainda mais. Em um 
disquete, o primeiro setor é sempre um setor de boot. 0 
MINIX permite de fato uma forma de particionar um dis¬ 
quete, mas apenas a primeira partição pode ser inicializa¬ 
da; não há registro-mestre de inicialização separado e as 
subpartições não são possíveis. Isso permite que disquetes 
particionados e não-particionados sejam montados exata¬ 
mente do mesmo modo. A principal utilização para um 
disquete particionado é que ele fornece uma maneira con¬ 
veniente de dividir um disco de instalação em uma ima¬ 
gem da raiz a ser copiada para um disco de RAM e uma 
porção montada que pode ser desmontada quando não for 
mais necessária, a fim de liberar a unidade de disquete para 
continuar o processo de instalação. 

0 setor de boot do MINIX é modificado no momento em 
que ele é gravado no disco atualizando os números de se¬ 
tor necessários para localizar um programa chamado boot 
em sua partição ou em sua subpartição. Essa atualização é 
necessária porque antes do carregamento do sistema ope¬ 
racional não há como utilizar os nomes de diretório e de 
arquivo para localizar um arquivo. Um programa especial 
chamado installboot é utilizado para fazer a atualização e 
a gravação do setor de boot. Boot é o carregador secundá¬ 
rio do MINIX. Mas ele pode fazer mais que apenas carregar 
o sistema operacional, uma vez que ele é um programa 
monitor que permite ao usuário mudar, configurar e sal- 
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Figura 2-31 As estruturas de disco utilizadas para fazer a inicialização, (a) Disco não-particionado. O primeiro setor é o bloco de 
boot. (b) Disco particionado. O primeiro setor é o registro-mestre de inicialização (master boot record). 


var vários parâmetros. Boot examina o segundo setor de 
sua partição a fim de localizar um conjunto de parâmetros 
para utilizar. O MINIX, como o UNIX padrão, reserva o pri¬ 
meiro bloco de 1K de cada dispositivo de disco como um 
bloco de boot, mas só um setor de 512 bytes é carregado 
pelo carregador de boot de ROM ou pelo setor de boot mes¬ 
tre, portanto, 512 bytes estão disponíveis para salvar as con¬ 
figurações. Essas controlam a operação de boot e também 
são passadas para o próprio sistema operacional. As confi¬ 
gurações-padrão apresentam um menu com uma opção, 
iniciar o MINIX, mas as configurações podem ser modifica¬ 
das para apresentar um menu mais complexo que permite 
iniciar outros sistemas operacionais (carregando e execu¬ 
tando setores de boot de outras partições), ou iniciar o MI- 
NIX com várias opções. As configurações-padrão também 
podem ser modificadas para saltar o menu e para iniciar o 
MINIX imediatamente. 

0 boot não é uma parte do sistema operacional, mas é 
suficientemente esperto para utilizar as estruturas de da¬ 
dos do sistema de arquivos para localizar a imagem real 
do sistema operacional. Por padrão, o boot procura um 
arquivo chamado /minix, ou, se houver um diretório / 
minix/, o arquivo mais recente dentro dele, mas os parâ¬ 
metros de boot podem ser mudados para procurar um ar¬ 
quivo com qualquer nome. Esse grau de flexibilidade não 
é usual, e a maioria dos sistemas operacionais tem um 
nome de arquivo predefinido para a imagem do sistema. 
Mas, o MINIX é um sistema operacional incomum que en¬ 
coraja os usuários a modificá-lo e a criar novas versões 
experimentais. A prudência exige que os usuários que fa¬ 
zem isso devem dispor de uma maneira de selecionar múl¬ 
tiplas versões, para serem capazes de retornar para a últi¬ 


ma versão que funcionou corretamente quando uma ex¬ 
periência fracassa. 

A imagem do MINIX carregado por boot é nada mais 
que uma concatenação dos arquivos individuais produzi¬ 
dos pelo compilador quando os programas kernel, geren¬ 
ciador de memória, sistema de arquivos e inil são compi¬ 
lados. Cada um desses inclui um cabeçalho curto do tipo 
definido em mclude/a.out.h , e a partir das informações 
no cabeçalho de cada parte, boot determina o espaço a re¬ 
servar para os dados não-inicializados depois de carregar o 
código executável e os dados inicializados para cada parte, 
de modo que a próxima parte possa ser carregada no ende¬ 
reço adequado. A matriz jsizes. mencionada na seção an¬ 
terior, também recebe uma cópia dessas informações para 
que o kernel possa ter acesso às localizações e aos tama¬ 
nhos de todos os módulos carregados por boot. As regiões 
de memória disponíveis para carregar o setor de boot, o 
próprio boot e o minix dependerão do hardware. Além dis¬ 
so, algumas arquiteturas de máquina podem requerer adap¬ 
tação de endereços internos dentro do código executável 
para corrigi-los para o endereço real onde um programa é 
carregado. A arquitetura segmentada dos processadores 
Intel torna isso desnecessário. Como os detalhes do proces¬ 
so de carregamento diferem com o tipo de máquina, e boot 
em si não é parte do sistema operacional, não nos apro¬ 
fundaremos mais nele aqui. O importante é que de uma 
maneira ou de outra o sistema operacional é carregado na 
memória. Uma vez que a carga esteja completa, o controle 
passa para o código executável do kernel. 

A propósito, devemos mencionar que sistemas operaci¬ 
onais não são universalmente carregados de discos locais. 
Estações de trabalho sem disco (diskless workstations) 
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podem carregar seus sistemas operacionais a partir de um 
disco remoto, por uma conexão de rede. isso requer sof¬ 
tware de rede em ROM, naturalmente. Embora os detalhes 
variem em relação ao que descrevemos aqui, de maneira 
geral, os elementos do processo são semelhantes. 0 código 
de ROM deve ser suficientemente inteligente para obter um 
arquivo executável pela rede que pode, então, obter o siste¬ 
ma operacional completo. Se o MIMX for carregado dessa 
maneira, muito pouco precisaria ser alterado no processo 
de inicialização que ocorre uma vez que o código do siste¬ 
ma operacional tenha sido carregado na memória. Natu¬ 
ralmente, ele precisará de um servidor de rede e de um sis¬ 
tema de arquivos modificado que possa acessar arquivos 
via rede. 

2.6.6 Inicialização do Sistema 

0 MIMX para máquinas tipo IBM PC pode ser compila¬ 
do no modo de 16 bits se for exigida compatibilidade com 
chips de processador mais antigos, ou no modo de 32 bits 
para melhor desempenho em processadores 80386 ou su¬ 
periores. O mesmo código-fonte em C é utilizado e o com¬ 
pilador gera a saída apropriada, que depende de o compi¬ 
lador ser da versão de 16 ou de 32 bits. Uma macro defini¬ 
da pelo compilador determina a definição da macro 
_WORD_ SIZE em include/minix/config.b. A primeira 
parte do MIMX a executar é escrita em linguagem assem- 
bly, e diferentes arquivos de código-fonte devem ser utili¬ 
zados para os compiladores de 16 ou de 32 bits. A versão de 
32 bits do código de inicialização está em mpx386.s. A al¬ 
ternativa, para sistemas de 16 bits. está em mpx88.s. Am¬ 
bos também incluem suporte de linguagem assem bly para 
outras operações de baixo nível do kernel. A seleção é feita 
automaticamente em mpx.s. Esse arquivo é tão curto que 
o arquivo inteiro pode ser apresentado na Figura 2-32. 

Mpx.s mostra uma utilização incomum da declaração 
#include do pré-processador C. Habitualmente #include é 
utilizado para incluir arquivos de cabeçalho, mas também 
pode ser utilizado para selecionar uma seção alternativa 
do código-fonte. Utilizar declarações #if para fazer isso exi¬ 
giria colocar todo o código dos dois grandes arquivos 
mpx88.s e mpx386.s em um único arquivo. Não apenas 
isso seria de difícil manejo como também desperdiçaria 
espaço em disco, uma vez que. em uma instalação parti¬ 
cular, é possível que um desses dois arquivos absolutamen¬ 
te não seja utilizado e possa ser arquivado ou excluído. Na 


discussão a seguir utilizaremos o mpx386.s, 32 bits, como 
exemplo. 

Como esse é nosso primeiro exame do código executá¬ 
vel, vamos começar com algumas palavras sobre como fa¬ 
remos esse exame ao longo de todo este livro. O grande 
número de arquivos-fonte utilizados na compilação de um 
programa em C de tamanho razoável pode ser difícil de 
acompanhar. Em geral, manteremos as discussões restri¬ 
tas a um único arquivo por vez e seguiremos em ordem 
pelos arquivos. Iniciaremos com o ponto de entrada para 
cada parte do sistema do mixix e seguiremos a linha de 
execução principal. Quando uma chamada para uma fun¬ 
ção de suporte for encontrada, diremos algumas palavras 
sobre o propósito da chamada, mas normalmente não en¬ 
traremos em uma descrição detalhada dos aspectos inter¬ 
nos da função nesse ponto, deixando isso para quando che¬ 
garmos à definição da função chamada. Funções subordi¬ 
nadas importantes normalmente são definidas no mesmo 
arquivo em que são chamadas, seguindo as funções de cha¬ 
mada de nível mais alto, mas as pequenas funções de pro¬ 
pósito geral, às vezes, são reunidas em arquivos separados. 
Além disso, tentamos ao máximo possível organizar o có¬ 
digo dependente de máquina em arquivos separados do 
código independente de máquina para facilitar a portabi¬ 
lidade para outras plataformas. Um esforço significativo 
foi dedicado para organizar o código, e, de fato, muitos 
arquivos foram reescritos no curso da redação deste texto 
para organizá-los melhor para o leitor. Mas um programa 
grande tem muitas ramificações e, às vezes, entender uma 
função principal requer a leitura das funções que ela cha¬ 
ma, portanto, ter algumas tiras de papel à mão para usar¬ 
mos como marcadores e desviar de nossa ordem de discus¬ 
são para ver as coisas em uma ordem diferente, às vezes, 
pode ser útil. 

Tendo exposto a maneira como organizamos a discus¬ 
são sobre o código, devemos iniciar imediatamente justifi¬ 
cando uma exceção importante. A inicialização do MIMX 
envolve várias transferências de controle entre as rotinas 
de linguagem assem bly em mpx386.s e rotinas escritas 
em C localizadas nos arquivos start.c e main.c. Descreve¬ 
remos essas rotinas na ordem em que elas são executadas, 
mesmo que isso envolva pular de um arquivo para outro. 

Uma vez que o processo de inicialização carregou o sis¬ 
tema operacional na memória, o controle é transferido para 
o rótulo MIMX (em mpx386.s, linha 6051). A primeira ins¬ 
trução é um salto sobre alguns bytes de dados; isso inclui 


#include <minix/config.h> 
#if_WORD_SIZE == 2 
#include “mpx88.s” 

#else 

#include “mpx386.s” 
#endif 


Figura 2-32 Como os arquivos-fonte alternativos de linguagem assembly são selecionados. 
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os sinalizadores do monitor de boot (linha 6054), utiliza¬ 
dos pelo monitor de boot para identificar várias caracterís¬ 
ticas do kernel , sobretudo se é um sistema de 16 ou de 32 
bits. O monitor de boot sempre inicia no modo de 16 bits, 
mas alterna a CPU para o modo de 32 bits se necessário. 
Isso acontece antes da passagem do controle para o mintx. 
O monitor também configura uma pilha. Há uma quanti¬ 
dade substancial de trabalho a ser feito pelo código de lin¬ 
guagem assembly: configurar uma estrutura de pilha para 
oferecer o ambiente adequado para código gerado pelo com¬ 
pilador de C, copiar as tabelas utilizadas pelo processador 
para definir segmentos de memória e configurar vários re¬ 
gistradores do processador. Logo que esse trabalho comple¬ 
ta-se, o processo de inicialização continua por meio da cha¬ 
mada (na linha 6109) da função em C cstart. Note que 
essa é referida como _cstart no código de linguagem as¬ 
sembly. Isso porque todas as funções compiladas pelo com¬ 
pilador C tem um sublinhado precedendo seus nomes nas 
tabelas de símbolos, e o linkeditor procura por esses nomes 
quando módulos compilados separadamente são vincula¬ 
dos. Como oassembler não adiciona sublinhados, o escri¬ 
tor de um programa em linguagem assembly deve explici¬ 
tamente adicionar um para o linkeditor ser capaz de loca¬ 
lizar o nome correspondente no arquivo-objeto gerado pelo 
compilador de C. Cstart chama outra rotina para iniciar 
na Tabela Global de Descritores a estrutura central de 
dados utilizada por processadores Intel de 32 bits para su¬ 
pervisionar a proteção de memória e a Tabela de Descri¬ 
tores de Interrupções, utilizada para selecionar o códi¬ 
go a ser executado para cada possível tipo de interrupção. 
Ao retornar de cstart, as instruções Igdt e lidt (linhas 6115 
e 6l 16) tornam essas tabelas efetivas carregando os regis¬ 
tradores dedicados por meio dos quais elas são endereça¬ 
das. A seguinte instrução, 

jmpf CS_SELECTOR:csinit 

parece, à primeira vista, uma não-operação, uma vez que 
transfere o controle para exatamente onde o controle esta¬ 
ria se houvesse uma série de instruções nop em seu lugar. 
Mas isso é uma parte importante do processo de inicializa¬ 
ção. Esse salto força a utilização das estruturas que acaba¬ 
ram de ser iniciadas. Após mais alguma manipulação dos 
registradores do processador, o MlNix termina com um sal¬ 
to (não uma chamada) da linha 6131 para o ponto de en¬ 
trada principal do kernel (em main.c). Nesse ponto, o có¬ 
digo de inicialização em mpx386.s está concluído. O resto 
do arquivo contém o código para iniciar ou para reiniciar 
uma tarefa ou processo, manipuladores de interrupção e 
outras rotinas de suporte que tiveram de ser escritas em 
linguagem assembly por razões de eficiência. Retornare¬ 
mos a elas na próxima seção. 

Agora veremos as funções de inicialização de alto nível 
em C. A estratégia geral é utilizar tanto quanto possível 
código de alto nível em C. Já há duas versões do código 
mpx, como vimos, e qualquer coisa que possa ser transpor¬ 
tada para o código em C elimina dois blocos de código as- 


sembler. A primeira coisa feita por cstart (em start.c. linha 
6524) é configurar os mecanismos de proteção da CPU e as 
tabelas de interrupção, chamando protjnit. Então, ela faz 
coisas como copiar os parâmetros de boot para a parte de 
memória do kernel e convertê-los em valores numéricos. 
Ela também determina o tipo de monitor de vídeo, o tama¬ 
nho da memória, o tipo de máquina, o modo de operação 
do processador (real ou protegido) e se um retorno para o 
monitor de boot é possível. Todas as informações são 
armazenadas em variáveis globais apropriadas, para aces¬ 
so quando necessário por qualquer parte do código do ker¬ 
nel. 

Main (em main.c. linha 6721) completa a inicializa¬ 
ção e, então, inicia a execução normal do sistema. Ela con¬ 
figura o hardware de controle de interrupção chamando 
intr_init. Isso é feito aqui porque não pode sê-lo até que o 
tipo de máquina seja conhecido, e o procedimento está em 
um arquivo separado porque é muito dependente do hard¬ 
ware. O parâmetro (1) na chamada informa intrjnit de 
que ele está inicializando para o MINTX. Com um parâme¬ 
tro (0), ele pode ser chamado para reinicializar o hard¬ 
ware para o estado original. A chamada a intrjnit tam¬ 
bém dá dois passos para assegurar que qualquer interrup¬ 
ção que ocorra antes que a inicialização esteja completa 
não tenha nenhum efeito. Primeiro um byte é gravado para 
cada chip controlador de interrupção para inibir a respos¬ 
ta para entrada externa. Então, todas as entradas na tabela 
utilizadas para acessar os manipuladores de interrupção 
específicos de cada dispositivo são preenchidas com o en¬ 
dereço de uma rotina que inofensivamente imprimirá uma 
mensagem se uma interrupção espúria for recebida. Mais 
tarde, essas entradas da tabela serão substituídas, uma a 
uma, por ponteiros para as rotinas dos manipuladores, uma 
vez que cada uma das tarefas de E/S executa sua própria 
rotina de inicialização. Cada tarefa então redefinirá um 
bit no chip controlador de interrupção para ativar sua pró¬ 
pria entrada de interrupção. 

Memjnit é chamada em seguida. Ela inicializa uma 
matriz que define a localização e o tamanho de cada bloco 
de memória disponível no sistema. Como acontece na ini¬ 
cialização do hardware de interrupção, os detalhes depen¬ 
dem do hardware, e o isolamento de memjnit como uma 
função em um arquivo separado mantém main livre de 
código que não é portável para hardware diferente. 

A parte maior do código de main é dedicada a configu¬ 
rar a tabela de processos para que quando as primeiras ta¬ 
refas e processos forem agendados, seus mapas de memó¬ 
ria e seus registradores estejam configurados corretamen¬ 
te. Todas as entradas na tabela de processos são marcadas 
como livres, e a mdlúzpproc _addr que acelera o acesso à 
tabela de processos é inicializada pelo laço nas linhas 6745 
a 6749. O código na linha 6748, 

(pproc_addr+ NR_TASKS)[t] = rp; 

poderia igualmente ter sido definido como 
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pproc_addr[t + NR_TASKS] = rp; 

porque na linguagem C a[i] é somente outro meio de es¬ 
crever *(a +i). Então, não faz muita diferença se você adi¬ 
cionar uma constante para a ou para i. Alguns compilado¬ 
res de C geram um código ligeiramente melhor se você adi¬ 
cionar uma constante a matriz em vez de ao índice. 

A parte maior de main, o longo laço das linhas 6762 a 
6815, inicializa a tabela de processos com as informações 
necessárias para executar as tarefas, os servidores e o init. 
Todos esses processos devem estar presentes no momento 
da inicialização e nenhum deles terminará durante a ope¬ 
ração normal. No início do laço, o endereço de uma entra¬ 
da de tabela de processos é atribuído a rp (linha 6763). 
Como rp é um ponteiro para uma estrutura, os elementos 
da estrutura podem ser acessados utilizando uma notação 
como rp->p_7iame. como é feito na linha 6765. Essa no¬ 
tação é utilizada extensamente no código-fonte do MINIX. 

As tarefas, naturalmente, são todas compiladas no mes¬ 
mo arquivo que o kernel. e as informações sobre seus re¬ 
quisitos de pilha estão na matriz tasktab definida em 
table.c. Como as tarefas são compiladas no kernel e po¬ 
dem chamar código e acessar dados localizados em qual¬ 
quer lugar no espaço do kernel, o tamanho de uma tarefa 
individual não é significativo, e o campo de tamanho de 
cada uma delas é preenchido com os tamanhos do próprio 
kernel. A matriz sizes contém os tamanhos de texto e de 
dados em cliks do kernel, gerenciador de memória, siste¬ 
ma de arquivos e init. Essas informações são atualizadas 
na área de dados do kernel por boot antes de o kernel co¬ 
meçar a executar e aparecem para o kernel como se o com¬ 
pilador as tivesse fornecido. Os primeiros dois elementos 
de sizes são os tamanhos de texto e de dados do kernel ; os 
dois seguintes são o gerenciador de memória e assim por 
diante. Se qualquer um dos quatro programas não utiliza 
espaço I e D separados, o tamanho do texto é 0; e texto e 
dados são agrupados juntos como dados. Atribuir a sizein- 
dex um valor de zero (linha 6775) para cada uma das ta¬ 
refas garante que o elemento zero áe. sizes nas linhas 6783 
e 6784 será acessado para todas as tarefas. A atribuição a 
sizeindex na linha 6778 dá a cada um dos servidores e a 
init seu próprio índice em sizes. 

O projeto original do IBM PC colocava a memória ROM 
no topo do intervalo de memória utilizável, que é limitado 
a 1MB em uma CPU 8088. Máquinas modernas compatí¬ 
veis com PC sempre têm mais memória do que o PC origi¬ 
nal, mas, por razões de compatibilidade, elas ainda têm 
memória ROM nos mesmos endereços que as máquinas 
mais antigas. Assim, a memória de leitura-escrita é des¬ 
contínua, com um bloco de ROM entre os 640KB inferiores 
e o intervalo superior acima de 1MB. O monitor de boot 
carrega os servidores e init no intervalo de memória acima 
da ROM se possível. Isso é feito principalmente para o be¬ 
nefício do sistema de arquivos, assim um cache de bloco 
maior pode ser utilizado sem colidir com a memória ROM. 
O código condicional nas linhas 6804 a 6810 assegura que 


essa utilização da área de memória alta é registrada na 
tabela de processos. 

Duas entradas na tabela de processos correspondem a 
processos que não precisam ser agendados da maneira 
usual. Esses processos são IDLE e HARDWARE. IDLE é um 
laço que não faz nada e é executado quando não há mais 
nada pronto para executar; o processo HARDWARE existe 
para fins de contabilidade — ele é creditado com o tempo 
utilizado para servir uma interrupção. Todos os demais pro¬ 
cessos são colocados nas filas apropriadas pelo código na 
linha 6811. A função chamada, lock_ready. configura uma 
variável de bloqueio, switching. antes de modificar as filas 
e, então, remover o bloqueio quando a fila foi modificada. 
O bloqueio e o desbloqueio não são requeridos neste ponto, 
quando nada ainda está executando, mas esse é o método- 
padrão e não há motivo para criar código extra para ser 
utilizado apenas uma única vez. 

O último passo na inicialização de cada entrada na ta¬ 
bela de processos é chamar alloc_ segments. Esse procedi¬ 
mento é parte da tarefa de sistema, mas naturalmente ne¬ 
nhuma tarefa ainda está executando, e ele é chamado como 
um procedimento normal na linha 6814. É uma rotina 
dependente de máquina que configura nos campos ade¬ 
quados as localizações, os tamanhos e os níveis de permis¬ 
são para os segmentos de memória utilizados por cada pro¬ 
cesso. Para processadores Intel mais antigos, que não su¬ 
portam modo protegido, ele define só as localizações de 
segmento. Ele teria de ser reescrito para gerenciar um tipo 
de processador com um método diferente de alocação de 
memória. 

Uma vez que a tabela de processos é inicializada para 
todas as tarefas, os servidores e init. o sistema está pratica¬ 
mente pronto para rodar. A variável bill _ptr informa qual 
processo é cobrado pelo tempo de processador; ela precisa 
ter um valor inicial configurado na linha 6818, e IDLE é 
uma escolha apropriada. Mais adiante, ele pode ser altera¬ 
do pela próxima função chamada, lock_pick Joroc. Todas 
as tarefas agora estão prontas para executar e bill_ptr será 
alterado quando um processo de usuário executar. Outro 
trabalho de lock_pick_procé fazer variável/>roc _ptr apon¬ 
tar para a entrada na tabela de processos do próximo pro¬ 
cesso a ser executado. Essa seleção é feita examinando as 
filas de tarefas, de servidores e de processos de usuário, nessa 
ordem. Nesse caso, o resultado é apontar proc_ptr para o 
ponto de entrada da tarefa de console, que é sempre a pri¬ 
meira a ser iniciada. 

Por fim, main entra no seu curso. Em muitos progra¬ 
mas em C, main é um laço, mas no kernel do UNIX seu 
trabalho está concluído, uma vez que a inicialização está 
completa. A chamada a restart na linha 6822 inicia a pri¬ 
meira tarefa. O controle nunca retornará a main. 

_Restart é uma rotina de linguagem assembly em 
mp.x386.s. De fato, jrestart não é uma função completa; 
é um ponto de entrada intermediário em um procedimen¬ 
to maior. Nós a discutiremos em detalhe na próxima se¬ 
ção; por enquanto diremos simplesmente que _restart cau- 
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sa uma comutação de contexto, de modo que o processo 
apontado por proc__ptr executará. Quando jrestart execu¬ 
tar pela primeira vez, poderemos dizer que o minix está 
executando — ele está executando um processo. _Restart 
é executado repetidas vezes à medida que as tarefas, os ser¬ 
vidores e os processos de usuário recebem suas oportuni¬ 
dades para executar e, então, são suspensos, seja para es¬ 
perar entrada, seja para dar vez a outro processo. 

A primeira tarefa enfileirada (a que utiliza a entrada 0 
da tabela de processos, ou seja, aquela com o número mais 
negativo) é sempre a tarefa de console, então, outras tare¬ 
fas podem utilizá-la para informar progresso ou proble¬ 
mas ao iniciarem. Ela executa até que bloqueie tentando 
receber uma mensagem. Então, a próxima tarefa executa¬ 
rá até que ela, também, bloqueie tentando receber uma 
mensagem. Por fim, todas as tarefas serão bloqueadas, de 
modo que o gerenciador de memória e o sistema de arqui¬ 
vos podem executar. Ao executar pela primeira vez, estes 
dois últimos farão alguma inicialização, mas ambos aca¬ 
barão bloqueando também. Por fim, init criará um pro¬ 
cesso getty para cada terminal. Esses processos bloquearão 
até que uma entrada seja digitada em algum terminal, 
ponto em que o primeiro usuário pode efetuar login. 

Acabamos de traçar a inicialização do minix por três 
arquivos, dois escritos em C e um em linguagem assembly. 
0 arquivo em linguagem assembly, mpx386.s , contém có¬ 
digo adicional utilizado no tratamento de interrupções, que 
veremos na próxima seção. Entretanto, antes de prosseguir, 
vamos encerrar esta parte com uma breve descrição das ro¬ 
tinas restantes nos dois arquivos em C. Os outros procedi¬ 
mentos em start.c são k_atoi (linha 6594), que converte 
uma string em um número inteiro, e k_getenv (linha 6606 ), 
que é utilizado para localizar entradas no ambiente do ker- 
nel, que é uma cópia dos parâmetros de boot. Essas são ver¬ 
sões simplificadas das funções-padrão de biblioteca que fo¬ 
ram reescritas aqui para manter o kernel simples. O único 
procedimento que resta em main.c é panic (linha 6829). 
Ele é chamado quando o sistema descobre uma condição 
que toma impossível continuar. Condições típicas de panic 
são um bloco crítico de disco que se tornou ilegível, um 
estado interno inconsistente que foi detectado ou uma par¬ 
te do sistema que chamou outra parte com parâmetros in¬ 
válidos. As chamadas para printf aqui são realmente cha¬ 
madas para a rotina printk do kernel, de modo que o ker¬ 
nel pode imprimir no console mesmo que a comunicação 
interprocesso normal seja interrompida. 

2.6.7 Tratamento de Interrupções no 

MINIX 

Os detalhes do hardware de interrupção são dependen¬ 
tes de sistema, mas qualquer sistema deve ter elementos 
funcionalmente equivalentes a esses descritos para siste¬ 
mas com CPUs Intel de 32 bits. As interrupções geradas por 
dispositivos de hardware são sinais elétricos e são gerenci¬ 
ados em primeiro lugar por um controlador de interrup¬ 


ções, um circuito integrado que pode capturar diversos des¬ 
ses sinais e gera para cada um deles um padrão único de 
dados no barramento de dados do processador. Isso é ne¬ 
cessário porque o processador em si tem apenas uma en¬ 
trada para detectar todos esses dispositivos e assim não pode 
diferenciar qual dispositivo precisa de serviço. Os PCs que 
utilizam processadores Intel de 32 bits normalmente são 
equipados com dois desses chips controladores. Cada um 
pode gerenciar oito entradas, mas um deles é um escravo 
que alimenta com sua saída uma das entradas do mestre, 
portanto 15 dispositivos externos distintos podem ser de¬ 
tectados pela combinação, como mostrado na Figura 2-33. 

Na figura, os sinais de interrupção chegam às várias 
linhas IRQ n mostradas à direita. A conexão com o pino 
INT da CPU informa ao processador que uma interrupção 
ocorreu. O sinal INTA (reconhecimento de interrupção) da 
CPU faz com que o controlador responsável pela interrup¬ 
ção coloque dados no barramento de dados do sistema in¬ 
formando ao processador qual rotina de serviço executar. 
O chip controlador de interrupção é programado durante 
a inicialização do sistema, quando main chama intrjnit. 
A programação determina a saída enviada para a CPU por 
um sinal recebido em cada uma das linhas de entrada, as¬ 
sim como vários outros parâmetros de operação do contro¬ 
lador. 0 dado colocado no barramento é um número de 8 
bits, utilizado para indexar em uma tabela com até 256 
elementos. A tabela do minix tem 56 elementos. Destes, 35 
realmente são utilizados; os outros são reservados para uti¬ 
lização em futuros processadores Intel ou para aprimora¬ 
mentos futuros do MINIX. Em processadores Intel de 32 bits, 
essa tabela contém descritores o portão de interrupção, cada 
um dos quais é uma estrutura de 8 bytes com vários cam¬ 
pos. 

Há vários modos de resposta possíveis a interrupções; 
no utilizado pelo minix, os campos de maior interesse para 
nós em cada um dos descritores de portão de interrupção 
apontam para o segmento de código executável da rotina 
de serviço e para o endereço inicial dentro dele. A CPU exe¬ 
cuta o código apontado pelo descritor selecionado. 0 resul¬ 
tado é exatamente o mesmo que executar uma instrução 

int <nnn> 

em linguagem assembly. A única diferença é que no caso 
de uma interrupção de hardware o <nnn> origina de um 
registrador no chip controlador de interrupção, e não de 
uma instrução na memória do programa. 

0 mecanismo de comutação de tarefas de um proces¬ 
sador Intel de 32 bits que é chamado para executar em 
resposta a uma interrupção é complexo, e alterar o conta¬ 
dor de programa para executar outra função é só uma par¬ 
te dele. Quando a CPU recebe uma interrupção enquanto 
está executando um processo, ela define uma nova pilha 
para utilizar durante o serviço de interrupção. A localiza¬ 
ção dessa pilha é determinada por uma entrada no Seg¬ 
mento de Estado de Tarefa i fask State Segment , TSS). 
Há uma estrutura dessas para o sistema inteiro, inicializa- 
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IRQ 0 (relógio) 

IRQ 1 (teclado) 

IRQ 3 (tty2) 

IRQ 4 (ttyl) 

IRQ 5 (Winchester do XT) 
IRQ 6 (disquete) 

IRQ 7 (impressora) 

IRQ 8 (relógio de tempo real) 
IRQ 9 (IRQ 2 redirecionada) 
IRQ 10 
IRQ 11 
IRQ 12 

IRQ 13 (exceção de FPU) 
IRQ 14 (Winchester do AT) 
IRQ 15 


Figura 2-33 Hardware de processamento de interrupções em um PC Intel de 32 bits. 


da por uma chamada de cstart a protjnit, e modificada à 
medida que cada processo é iniciado. 0 efeito é que a nova 
pilha criada por uma interrupção sempre inicia no fim da 
estrutura stackframe_s dentro da entrada da tabela de pro¬ 
cesso do processo interrompido. A CPU automaticamente 
coloca vários registradores nessa nova pilha, incluindo 
aqueles necessários para restaurar a pilha do próprio pro¬ 
cessos interrompido e restaurar seu contador-programa. 
Quando o código do manipulador de interrupção começa 
a executar, ele utiliza essa área na tabela de processos como 
sua pilha, e muitas das informações necessárias para re¬ 
tornar ao processo interrompido já terão sido armazena¬ 
das. 0 manipulador de interrupção coloca na pilha o con¬ 
teúdo dos registradores adicionais, preenchendo a estrutu¬ 
ra de pilha e, então, alterna para uma pilha fornecida pelo 
kernel enquanto faz o que for necessário para servir a in¬ 
terrupção. 

0 término de uma rotina de serviço de interrupção é 
feito alternando a pilha, a partir da pilha do kernel de vol¬ 
ta a uma estrutura de pilha na tabela de processos (mas 
não necessariamente a mesma que foi criada pela última 
interrupção), retirando da pilha explicitamente os regis¬ 
tradores adicionais e executando uma instrução iretd (re¬ 
torno de interrupção). Iretd restaura o estado que existia 
antes da interrupção, restaurando os registradores que fo¬ 
ram colocados na pilha pelo hardware e comuta para a 
pilha que estava em utilização antes da interrupção. Por¬ 
tanto, uma interrupção pára um processo, e a conclusão 
do serviço de interrupção reinicia um processo, possivel¬ 
mente um diferente daquele que foi recentemente inter¬ 
rompido. Diferentemente dos mecanismos de interrupção 


mais simples, que são o assunto normal dos textos de pro¬ 
gramação de linguagem assembly, nada é armazenado na 
pilha do processo interrompido durante uma interrupção. 
Além disso, como a pilha é criada de novo em uma locali¬ 
zação conhecida (determinada pelo TSS) depois de uma 
interrupção, o controle de múltiplos processos é simplifi¬ 
cado. Para iniciar um processo diferente, tudo que é neces¬ 
sário é apontar o ponteiro da pilha para a estrutura de pi¬ 
lha de outro processo, retirada da pilha dos registradores 
que explicitamente foram lá acrescentados, e executar uma 
instrução iretd. 

A CPU desativa todas as interrupções quando recebe uma 
interrupção. Isso garante que não ocorrerá nada que possa 
causar o estouro da estrutura de pilha dentro de uma en¬ 
trada na tabela de processos. Isso é automático, mas tam¬ 
bém existem instruções no nível assembly para desativar e 
para ativar interrupções. 0 manipulador de interrupção rea¬ 
tiva as interrupções depois de alternar para a pilha do ker¬ 
nel, localizada fora da tabela de processos. Ele deve desati¬ 
var todas as interrupções novamente antes de alternar de 
volta para uma pilha dentro da tabela de processos, natu¬ 
ralmente, mas enquanto está manipulando uma interrup¬ 
ção, outras interrupções podem ocorrer e serem processa¬ 
das. A CPU monitora interrupções aninhadas e emprega 
um método simplificado para alternar de uma rotina de 
serviço de interrupção e retornar de uma quando um ma¬ 
nipulador de interrupção é interrompido. Quando uma 
nova interrupção é recebida enquanto o manipulador (ou 
outro código do kernel) está executando, uma nova pilha 
não é criada. Em vez disso, a CPU coloca na pilha existente 
registradores essenciais necessários para retomar o código 
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interrompido. Quando um iretd é encontrado durante a 
execução do código do kemel, um mecanismo simplifica¬ 
do de retorno é utilizado também. 0 processador pode de¬ 
terminar como gerenciar o iretd examinando o seletor de 
segmento de código que é retirado da pilha como parte da 
ação de iretd. 

Os níveis de privilégio mencionados anteriormente con¬ 
trolam as diferentes respostas a interrupções recebidas en¬ 
quanto um processo está executando ou enquanto o códi¬ 
go do kernel (incluindo rotinas de serviço de interrupção) 
está executando. O mecanismo mais simples é utilizado 
quando o nível de privilégio do código interrompido é o 
mesmo que o nível de privilégio do código sendo executa¬ 
do em resposta à interrupção. É só quando o código inter¬ 
rompido tem privilégio inferior ao código do serviço de in¬ 
terrupção que o mecanismo mais elaborado, utilizando o 
TSS e uma nova pilha, é empregado. 0 nível de privilégio 
de um segmento de código é registrado no seletor de seg¬ 
mento de código e como este é um dos itens empilhados 
durante uma interrupção, ele pode ser examinado ao re¬ 
tornar da interrupção para determinar o que a instrução 
iretd deve fazer. Outro serviço é fornecido pelo hardware 
quando uma nova pilha é criada para uso enquanto ser¬ 
vindo uma interrupção. O hardware faz uma verificação 
para assegurar-se de que a nova pilha é suficientemente 
grande para, pelo menos, suportar a quantidade mínima 
de informações que deve ser colocada nela. Isso evita que o 
código mais privilegiado do kernel seja acidentalmente (ou 
maliciosamente) derrubado por um processo de usuário 
fazendo uma chamada de sistema com uma pilha inade¬ 
quada. Esses mecanismos são construídos no processador 
especificamente para uso na implementação de sistemas 
operacionais que suportam múltiplos processos. 

Esse comportamento pode causar confusão se você não 
estiver familiarizado com o funcionamento interno das 
CPUs Intel de 32 bits. Normalmente tentamos evitar des¬ 
crever tais detalhes, mas entender o que acontece quando 
uma interrupção ocorre e quando uma instrução iretd é 
executada é essencial para compreender como o kernel 
controla as transições para e a partir do estado “em execu¬ 
ção” da Figura 2-2.0 fato de que o hardware gerencia gran¬ 
de parte do trabalho torna a vida muito mais fácil para o 
programador e presumivelmente torna o sistema resultan¬ 
te mais eficiente. Toda essa ajuda do hardware, entretanto, 
toma realmente muito difícil entender o que está aconte¬ 
cendo a partir da simples leitura do software. 

Só uma parte minúscula do kernel do minix realmente 
vê as interrupções de hardware. Esse código está em 
mpx386.s. Aqui há um ponto de entrada para cada inter¬ 
rupção. O código-fonte em cada ponto de entrada, 
JiwintOO a _hwint07, (linhas 6l64 a 6193) parece-se com 
uma chamada a hwint_master (linha 6143), e os pontos 
de entrada _hwint08 a _hwintl5 (linhas 6222 a 6251) 
parecem-se com chamadas a hwint_slave (linha 6199 ) • 
Cada ponto de entrada parece passar um parâmetro na cha¬ 
mada, indicando qual dispositivo precisa de serviço. De fato, 
essas não são realmente chamadas, mas macros, e oito có¬ 


pias separadas do código definido pela definição de maero 
de hwintjnaster são montados com apeiras o parâmetro 
irq diferente. De maneira semelhante, oito cópias da ma¬ 
cro hwint_slave são montadas. Isso pôde parecer extrava¬ 
gante, mas o código montado é bastante compacto. O có¬ 
digo-objeto de cada macro expandida ocupa menos de 40 
bytes. Ao servir uma interrupção, a velocidade é importan¬ 
te e fazendo dessa maneira eliminamos o acréscimo de 
executar código para carregar um parâmetro, chamar uma 
sub-rotina e recuperar o parâmetro. 

Continuaremos a discussão sobre hwint jnaster como 
se ela realmente fosse uma única função em vez de uma 
macro que é expandida em oito lugares diferentes. Lem¬ 
bre-se de que antes de hwint jnaster começar a executar, 
a CPU criou uma nova pilha na estrutura de pilha do pro¬ 
cesso interrompido, dentro de sua entrada na tabela de pro¬ 
cessos e que vários registradores-chave já foram salvos aí. 
A primeira ação de hwint jnaster é chamar save (linha 
6144). Essa sub-rotina coloca na pilha todos os outros re¬ 
gistradores necessários para reiniciar o processo interrom¬ 
pido. Save poderia ter sido escrita inline' como parte da 
macro para aumentar a velocidade, mas isso teria mais 
que dobrado o tamanho da macro e, em qualquer caso. 
save é necessária para chamadas por outras funções. Como 
veremos, save faz alguns truques com a pilha. Ao retornar 
para hwint jnaster, a pilha do kernel, não uma estrutura 
de pilha na tabela de processos, está em utilização. O pró¬ 
ximo passo é manipular o controlador de interrupções, para 
impedi-lo de receber outra interrupção da origem que ge¬ 
rou a atual interrupção (linhas 6145 a 6147). Essa opera¬ 
ção mascara a capacidade do chip controlador de respon¬ 
der a uma entrada em particular; a capacidade da CPU de 
responder a todas interrupções é inibida internamente 
quando ela recebe pela primeira vez o sinal de interrupção 
e ainda não foi restaurada nesse ponto. 

O código nas linhas 6148 a 6150 redefine o controlador 
de interrupção e, então, ativa a CPU novamente para rece¬ 
ber interrupção de outras fontes. Em seguida, o número da 
interrupção que está sendo servida é utilizado pela instru¬ 
ção call indireta na linha 6152 como índice em uma tabe¬ 
la de endereços das rotinas de baixo nível específicas de 
cada dispositivo. Chamamos essas rotinas de baixo nível, 
mas elas são escritas em C e, em geral, executam opera¬ 
ções como servir um dispositivo de entrada e transferir os 
dados para um buffer onde podem ser acessados quando a 
tarefa correspondente tem sua próxima chance de execu¬ 
tar. Uma quantidade substancial de processamento pode 
acontecer antes do retorno dessa chamada. 

Veremos exemplos de código de driver de baixo nível 
no próximo capítulo. Entretanto, para entender o que está 
acontecendo aqui em hwint jnaster, mencionamos agora 
que o código de baixo nível pode chamar interrupt (em 
proc.c, que discutiremos na próxima seção) e que inter¬ 
rupt transforma a interrupção em uma mensagem para a 


*N. de R. Técnica em que cada chamada de rotina é substituída pelo 
seu código completo. 
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tarefa que serve o dispositivo que causou a interrupção. 
Além disso, uma chamada a interrupt invoca o agendador 
e pode selecionar essa tarefa para executar em seguida. Ao 
retornar da chamada para o código específico ao dispositi¬ 
vo, a capacidade do processador de responder a todas inter¬ 
rupções é novamente desativada, pela instrução cli na li¬ 
nha 6154, e o controlador de interrupção é preparado para 
ser capaz de responder ao dispositivo que causou a atual 
interrupção quando todas as interrupções forem reativa¬ 
das em seguida (linhas 6157 a 6159) ■ Então, buintjnaster 
termina com uma instrução ret (linha 6l60). Não é óbvio 
que um truque acontece aqui. Se um processo foi inter¬ 
rompido, a pilha em utilização neste ponto é a pilha do 
kernel e não a pilha dentro da tabela de processos que foi 
configurada pelo hardware antes de hwint_master ser ini¬ 
ciado. Nesse caso, a manipulação da pilha por save terá 
deixado o endereço de _restart na pilha do kernel. Isso faz 
com que uma tarefa, um servidor ou um processo de usu¬ 
ário execute mais uma vez. Esse pode não ser, e aliás é im¬ 
provável que seja, o mesmo processo que estava executan¬ 
do originalmente; isso depende do processamento da men¬ 
sagem criado pela rotina de serviço de interrupção especí¬ 
fica do dispositivo ter causado uma alteração no processo 
de agendamento. Esse, então, é o coração ao mecanismo 
que cria a ilusão de múltiplos processos executando simul¬ 
taneamente. 

Para concluir, devemos mencionar que quando uma 
interrupção ocorre enquanto o código do kernel está exe¬ 
cutando, a pilha do kernel já está em utilização esave dei¬ 
xa o endereço de restartl na pilha do kernel. Nesse caso, o 
que quer que o kernel estivesse fazendo anteriormente con¬ 
tinua após o ret no fim de huint_master. Portanto, as in¬ 
terrupções podem ser aninhadas, mas quando todas as ro¬ 
tinas de serviço de baixo nível estão completas _restart por 
fim executará, e um processo diferente do que foi inter¬ 
rompido pode ser colocado em execução. 

Hwint_slave (linha 6199) é muito semelhante a 
hwint_master, exceto que deve reativar ambos os contro¬ 
ladores, mestre e escravo, uma vez que os dois foram desa¬ 
tivados pela recepção de uma interrupção pelo escravo. Há 
alguns aspectos sutis da linguagem assembly que são vis¬ 
tos aqui. Primeiro, na linha 6206 há uma linha 

jmp .+ 2 

que especifica um salto cujo endereço-alvo é a instrução 
imediatamente seguinte. Essa instrução está colocada aqui 
unicamente para adicionar uma pequena pausa. Os auto¬ 
res do BIOS original do IBM PC consideraram uma pausa 
necessária entre instruções de E/S consecutivas e estamos 
seguindo seu exemplo, embora essa pausa possa não ser 
necessária nos atuais computadores compatíveis com IBM 
PC. Esse tipo de ajuste fino é uma boa razão por que pro¬ 
gramar dispositivos de hardware seja considerado um ofí¬ 
cio esotérico por algumas pessoas. Na linha 6214, há um 
salto condicional para uma instrução com um rótulo nu¬ 
mérico, 


0: ret 

a ser encontrado na linha 6218. Note que a linha 
jz Of 

não especifica um número de bytes a saltar, como no exem¬ 
plo anterior. 0 Of aqui não é um número hexadecimal. 
Essa é a maneira como o assembler utilizado pelo compi¬ 
lador MINIX especifica um rótulo local; o Of significa um 
salto para frente do próximo rótulo numerado com 0. 
Nomes de rótulo normais não podem começar com carac¬ 
teres numéricos. Outro interessante e possivelmente con¬ 
fuso ponto é que o mesmo rótulo ocorre em outra parte do 
mesmo arquivo, nalinha. èl60 em huint_masler. Asitua- 
ção é ainda mais complicada do que parece à primeira vis¬ 
ta, uma vez que esses rótulos estão dentro de macros e as 
macros são expandidas antes de o montador ver esse códi¬ 
go. Assim, há realmente 16 rótulos 0: no código visto pelo 
montador. A possível proliferação de rótulos declarados den¬ 
tro de macros é, de fato, a razão por que a linguagem as¬ 
sembly fornece rótulos locais; ao resolver um rótulo local, 
o montador utiliza aquele mais próximo que coincide com 
a direção especificada, e as outras ocorrências de um rótu¬ 
lo local são ignoradas. 

Agora passemos a examinar save (linha 6261), que já 
mencionamos várias vezes. Seu nome descreve uma de suas 
funções, que é salvar o contexto do processo interrompido 
na pilha fornecida pela CPU, que é uma estrutura de pilha 
dentro da tabela de processos. Save utiliza a variável 
_k_reenter para contar e para determinar o nível de ani- 
nhamento das interrupções. Se um processo estava execu¬ 
tando quando a atual interrupção ocorreu, a instrução 

mov esp, k_stktop 

na linha 6274 alterna para a pilha do kernel, e a instrução 
seguinte coloca na pilha o endereço de _restart (linha 
6275). Caso contrário, a pilha do kernel jáestá em uso e o 
endereço d erestartl é colocado na pilha (linha 6281). Em 
qualquer caso, com uma pilha em utilização possivelmen¬ 
te diferente da que estava em efeito na entrada, e com o 
endereço de retorno na rotina que a chamou enterrado 
embaixo dos registradores que ela acabou de colocar na 
pilha, uma simples instrução return não é adequada para 
retornar para o procedimento que fez a chamada. As ins¬ 
truções 

jmp RETADR-P_STACKBASE(eax) 

que terminam os dois pontos de saída de save, na linha 
6277 e na linha 6282, utilizam o endereço que foi coloca¬ 
do na pilha quando save foi chamada. 

0 próximo procedimento em mpx386.s é _s_call, que 
começa na linha 6288. Antes de examinar seus detalhes 
internos, vejamos como ele termina. Não há nenhum ret 
ou jmp no seu fim. Após desativar as interrupções com o cli 
na linha 6315, a execução continua em _restart. _S_call 
é a chamada de sistema correspondente do mecanismo de 
tratamento de interrupção. 0 controle chega a _s_call se- 
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guindo uma interrupção de software, isto é, a execução de 
uma instrução int nnn. As interrupções de software são tra¬ 
tadas como interrupções de hardware, exceto que, natural¬ 
mente, o índice na Tabela de Descritores de Interrupção é 
codificado na parte nnn de uma instrução int jmn, em vez 
de ser fornecida por um chip controlador de interrupções. 
Assim, quando se entrou em _j_call, a CPU já alternou 
para uma pilha dentro da tabela de processos (fornecida 
pelo TSS) e vários registradores já foram acrescentados a 
essa pilha. Caindo para _restart, a chamada a _s_call por 
fim termina com uma instrução iretd, e, assim como nas 
interrupções de hardware, essa instrução iniciará qualquer 
que seja o processo apontado por proc_ptr nesse ponto. A 
Figura 2-34 compara o gerenciamento de uma interrup¬ 
ção de hardware e de uma chamada de sistema utilizando 
o mecanismo de interrupção de software. 

Vejamos agora alguns detalhes de _s_call. 0 rótulo al¬ 
ternativo, _p_s_call. é um vestígio da versão de 16 bits do 
MiNix, que tem rotinas separadas para operação no modo 
protegido e no modo real. Na versão de 32 bits todas as 
chamadas a qualquer rótulo acabam aqui. Um programa¬ 
dor que invoca uma chamada de sistema do MIMX escreve 
uma chamada de função em C que se parece com qual¬ 
quer outra chamada de função, seja para uma função lo¬ 
calmente definida ou para uma rotina na biblioteca de C. 
0 código da biblioteca que suporta uma chamada de siste¬ 
ma configura uma mensagem, carrega o endereço da men¬ 
sagem e o id do processo de destino em registradores de 
CPU e, então, invoca uma instrução int SYS386_VECT0R. 
Como descrito acima, o resultado é que o controle passa 



(a) 

Figura 2-34 (a) Como uma interrupção de hardware 


para o início de _s_call e vários registradores já foram 
acrescentados a uma pilha dentro da tabela de processos. 

A primeira parte do código _s_call assemelha-se a uma 
expansão inline desave e salva os registradores adicionais 
que devem ser conservados. Assim como em save, uma ins¬ 
trução 

mov esp, k_stktop 

alterna, então, para a pilha do kernel, e as interrupções 
são reativadas (a semelhança de uma interrupção de sof¬ 
tware com uma interrupção de hardware estende-se a am¬ 
bos desativando todas as interrupções). Seguindo, vem uma 
chamada a _jys_call, que discutiremos na próxima se¬ 
ção. Por enquanto, simplesmente diremos que ela faz com 
que uma mensagem seja enviada, e que esta última, por 
sua vez, faz com que o agendador seja executado. Assim, 
quando _sys_call retorna, é provável qu eproc_ptr esteja 
apontando para um processo diferente do que iniciou a 
chamada de sistema. Antes de a execução ir para restart, 
uma instrução cli desativa as interrupções para proteger a 
estrutura de pilha do processo que está para ser iniciado. 

Vimos que _restart (linha 6322) é alcançado de várias 
maneiras: 

1. Por uma chamada a partir de main, quando o sis¬ 
tema inicia. 

2. Por um salto a partir de hwint_master ou 
hwint_slave, após uma interrupção de hardware. 

3. Por meio de _s_call, após uma chamada de siste¬ 
ma. 



(b) 

é processada, (b) Como uma chamada de sistema é feita. 
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Em cada caso, as interrupções são desativadas neste 
ponto. _Restart chama unbold se detecta que qualquer 
interrupção não-servida foi contida porque chegou enquan¬ 
to outras interrupções estavam sendo processadas. Isso per¬ 
mite que outra interrupção seja convertida em mensagens 
antes de qualquer processo ser reiniciado. Isso temporaria¬ 
mente reativa as interrupções, mas elas são desativadas 
novamente antes de unbold retornar. Na linha 6333, o pró¬ 
ximo processo a executar foi definitivamente escolhido, e 
com as interrupções desativadas ele não pode ser alterado. 
A tabela de processos foi cuidadosamente construída para 
começar com uma estrutura de pilha, e a instrução nessa 
linha, 

mov esp, (_proc_ptr) 

aponta o ponteiro de pilha da CPU para a estrutura da pi¬ 
lha. A instrução 

lldt P_LDT_SEL (esp) 

carrega então o registrador da tabela descritora local do 
processador a partir da estrutura de pilha. Isso prepara o 
processador para utilizar os segmentos de memória que per¬ 
tencem ao próximo processo a ser executado. A instrução 
seguinte carrega o endereço na entrada de tabela de pro¬ 
cessos do próximo processo, que é onde a pilha para a pró¬ 
xima interrupção será configurada, e a instrução seguinte 
armazena esse endereço no TSS. A primeira parte de _res- 
tart não é necessária depois que uma interrupção ocorrida 
quando o código do kernel (incluindo o código do serviço 
de interrupção) estava executando, uma vez que a pilha 
do kernel estará em utilização, e o término do serviço de 
interrupção permite que o código do kernel continue. 0 
rótulo restartl (linha 6337) marca o ponto onde a execu¬ 
ção é reassumida neste caso. Neste ponto k_reenter é de- 
crementado para registrar o nível de interrupções possivel¬ 
mente aninhadas que foram descartadas, e as instruções 
restantes restauram o processador para o estado em que ele 
estava quando o próximo processo executou pela última 
vez. A penúltima instrução modifica o ponteiro da pilha de 
tal modo que o endereço de retorno que foi colocado na 
pilha quando save foi chamada é ignorado. Se a última 
interrupção ocorreu quando um processo estava executan¬ 
do, a instrução final, iretd, completa o retorno à execução 
de qualquer que seja o processo que tenha permissão para 
executar em seguida, restaurando seus registradores res¬ 
tantes, incluindo seu segmento de pilha e o ponteiro de 
pilha. Se, porém, esse encontro com o iretd ocorreu via res¬ 
tartl, a pilha em utilização pelo kernel não é uma estru¬ 
tura de pilha, mas sim a pilha do kernel, e isso não é um 
retorno para um processo interrompido, mas sim o térmi¬ 
no de uma interrupção que ocorreu enquanto o código do 
kernel estava executando. A CPU detecta isso quando o des¬ 
critor de segmento de código é retirado da pilha durante 
execução de iretd, e a ação completa de iretd neste caso é 
manter a pilha do kernel em utilização. 


Há mais algumas coisas a discutir sobre mpx386.s. 
Além das interrupções de hardware e de software, várias 
condições de erro internas à CPU podem causar uma ex¬ 
ceção. As exceções não são sempre ruins. Elas podem ser 
utilizadas para estimular o sistema operacional a oferecer 
um serviço, como fornecer mais memória para um proces¬ 
so utilizar, ou para carregar de uma página de memória 
que foi movida para o disco, embora tais serviços não se¬ 
jam implementados no MlMX-padrão. Mas, quando ocorre 
uma exceção, ela não deve ser ignorada. As exceções são 
gerenciadas pelo mesmo mecanismo que as interrupções, 
utilizando descritores na Tabela de Descritores de Interrup¬ 
ção. Essas entradas na tabela apontam para os 16 pontos 
de entrada de manipuladores de exceção, começando com 
_divide_error e terminando com _copr_error, localiza¬ 
dos perto do final de mp.\386.s, nas linhas 6350 a 6412. 
Todos esses saltam para exception (linha 6420) ou errex- 
ception (linha 6431) dependendo de se a condição acres¬ 
centa um código de erro à pilha ou não. O gerenciamento 
aqui, no código assembly, é semelhante ao que nós já vi¬ 
mos. Os registradores são colocados na pilha, e a rotina em 
C jexception (note o sublinhado) é chamada para geren¬ 
ciar o evento. As consequências das exceções variam. Algu¬ 
mas são ignoradas, algumas causam pânico e algumas re¬ 
sultam no envio de sinais aos processos. Examinaremos 
_exceptíon em uma seção posterior. 

Há um outro ponto de entrada que é gerenciado como 
uma interrupção, _level0_ call (linha 6458). Sua função 
será discutida na próxima seção, quando discutiremos o 
código para o qual ele salta, _level0 _Junc. O ponto de en¬ 
trada está aqui em mpx386.s junto com os pontos de en¬ 
trada de interrupção e de exceção porque ele também é 
invocado pela execução de uma instrução int. Como as ro¬ 
tinas de exceção, ele chama wi? e, assim, por fim o código 
que salta para cá terminará com um ret que conduz a _res- 
tart. A última função executável em mpx386.s é _idle_task 
(linha 6465). Essa é um laço que não faz nada e é execu¬ 
tada sempre que não há outro processo pronto para execu¬ 
tar. 

Finalmente, algum espaço de armazenamento de da¬ 
dos é reservado no fim do arquivo de linguagem assembly. 
Há dois diferentes segmentos de dados definidos aqui. A 
declaração 

.sect .rom 

na linha 6478 assegura que esse espaço de armazenamen¬ 
to é alocado bem no começo do segmento de dados do ker¬ 
nel. O compilador põe um número mágico aqui para que 
boot possa verificar se o arquivo que ele carrega é uma 
imagem válida do kernel. Boot , então, sobrescreve o nú¬ 
mero mágico e o espaço subseqüente com a matriz de da¬ 
dos _sizes, como descrito na discussão sobre estruturas de 
dados do kernel. Espaço suficiente é reservado para uma 
matriz _jizes com um total de 16 entradas, no caso de ser- 
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vidores adicionais serem adicionados ao mintx. A outra área 
de armazenamento de dados definida na declaração 

.sect .bss 

(linha 6483) reserva espaço na área normal de variáveis 
não-inicializadas do kernel para a pilha do kernel e para 
variáveis utilizadas pelos manipuladores de exceção. Ser¬ 
vidores e processos normais têm espaço de pilha reservado 
quando um arquivo executável é vinculado e dependem do 
kernel para configurar adequadamente o descritor de seg¬ 
mento de pilha e o ponteiro de pilha quando são executa¬ 
dos. 0 kernel tem de fazer isso sozinho. 

2.6.8 Comunicação Interprocesso no 
MINIX 

Os processos no MINTX comunicam-se por mensagens, 
utilizando o princípio do rendez-vous. Quando um pro¬ 
cesso faz um sexd, a camada mais baixa do kernel verifica 
se o destino está esperando uma mensagem do remetente 
(ou de qualquer remetente). Se estiver, a mensagem é co¬ 
piada do buffer do remetente para o buffer do destinatário, 
e os dois processos são marcados como executáveis. Se o 
destino não estiver esperando uma mensagem do reme¬ 
tente, este último é marcado como bloqueado e colocado 
em uma fila de processos esperando poder enviar para o 
destinatário. 

Quando um processo faz um RKCKIVK, o kernel verifica 
se qualquer processo está enfileirado tentando enviar para 
ele. Se estiver, a mensagem é copiada do remetente bloque¬ 
ado para o destinatário, e ambos são marcados como exe¬ 
cutáveis. Se nenhum processo estiver enfileirado tentando 
enviar para ele, o destinatário bloqueia ate' a chegada de 
uma mensagem. 

0 código de alto nível para comunicação interprocesso 
está localizado em proc.c. 0 trabalho do kernel é traduzir 
uma interrupção de hardware ou uma interrupção de sof¬ 
tware em uma mensagem. A primeira é gerada por har¬ 
dware e a última é a maneira como uma requisição de 
serviços do sistema, isto é, uma chamada de sistema, é co¬ 
municada ao kernel. Esses casos são tão semelhantes que 
poderiam ser gerenciados por uma única função, mas foi 
mais eficiente criar duas funções especializadas. 

Primeiro veremos interrupt (linha 6938). Essa é cha¬ 
mada pela rotina do serviço de interrupção de baixo nível 
para um dispositivo depois de receber uma interrupção de 
hardware. A função de interrupt é converter a interrupção 
em uma mensagem para a tarefa que gerencia o dispositi¬ 
vo que gerou interrupção, e geralmente muito pouco é fei¬ 
to antes de chamar interrupt. Por exemplo, todo manipu¬ 
lador de interrupção de baixo nível para o driver de disco 
rígido consiste nessas três linhas tão-somente: 

w status = in_byte(w_wn->base + REG_S7A7T/S); /* 

reconhecimento da interrupção */ 
interrupt(WINCHESTER); 
return 1; 


Se não fosse necessário ler uma porta de E/S no controla¬ 
dor de disco rígido para obter o status, a chamada a inter¬ 
rupt poderia ficar em mpx386.s em vez de em at_wini.c. 
A primeira coisa que interrupt faz é verificar se uma inter¬ 
rupção já estava sendo servida quando a interrupção atual 
foi recebida, olhando na variável kjreenter (linha 6962 ). 
Nesse caso, a interrupção atual é enfileirada, e interrupt 
retorna. A interrupção atual será servida mais adiante, 
quando unbold for chamado. A próxima ação é verificar se 
a tarefa está esperando uma interrupção (linhas 6978 a 
6981). Se a tarefa não estiver pronta para receber, seu sina- 
lizador p_int_blocked é ligado — veremos mais adiante 
que isso possibilita recuperar a interrupção perdida — e 
nenhuma mensagem é enviada. Se passar nesse teste, a 
mensagem é enviada. Enviar uma mensagem de HARD¬ 
WARE para uma tarefa é simples, porque as tarefas e 0 ker¬ 
nel são compiladas no mesmo arquivo e podem acessar as 
mesmas áreas de dados. 0 código nas linhas 6989 a 6992 
envia a mensagem, preenchendo os campos de origem e 
tipo do buffer de mensagem da tarefa de destino, redefi¬ 
nindo 0 sinalizador RECEMNG do destino e desbloquean¬ 
do a tarefa. Uma vez que a mensagem está pronta, a tarefa 
de destino é agendada para executar. Discutiremos agen- 
damento em mais detalhe na próxima seção, mas 0 código 
de interrupt nas linhas 6997 a 7003 fornece uma visuali¬ 
zação do que veremos — é um substituto inline para 0 
procedimento ready que e' chamado para enfileirar um 
processo. Ele é simples aqui, uma vez que as mensagens 
originárias de interrupções vão só para tarefas e, portanto, 
não há nenhuma necessidade de determinar qual das três 
filas de processos precisa ser alterada. 

A próxima função em proc.c é sys_call. Ela tem uma 
função semelhante a interrupt: converte uma interrupção 
de software (a instrução m\SYS386_VECTOR por meio da 
qual uma chamada de sistema é iniciada) em uma men¬ 
sagem. Mas como há um intervalo maior de possíveis ori¬ 
gens e de destinos nesse caso, e como a chamada pode re¬ 
querer que se envie e/ou receba uma mensagem, sys_call 
tem mais trabalho a fazer. Como é freqüentemente 0 caso, 
isso significa que 0 código para sys_call é curto e simples, 
já que faz a maioria do seu trabalho chamando outros pro¬ 
cedimentos. A primeira dessas chamadas é para isoksrc_ 
dest. uma macro definida emproe.b (linha 5172), que in¬ 
corpora ainda outra macro, isokprocn. também definida 
em proc.b (linha 5171). 0 efeito é verificar se 0 processo 
especificado como a origem ou 0 destino da mensagem é 
válido. Na linha 7026 um teste semelhante, isuserp (tam¬ 
bém uma macro definida em proc.b). é executado para 
garantir que, se a chamada é de um processo de usuário, 
ele deve estar solicitando 0 envio de uma mensagem e, en¬ 
tão, aguardando uma resposta, 0 único tipo de chamada 
permitido a processos de usuário. Esse tipo de erro é im¬ 
provável, mas os testes são facilmente feitos, já que aca¬ 
bam sendo compilados no código para executar compara¬ 
ções de números inteiros pequenos. Nesse nível mais bási¬ 
co do sistema operacional, é aconselhável fazer testes para 
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os erros mais improváveis. Esse código pode executar mui¬ 
tas vezes por segundo a cada segundo de atividade do siste¬ 
ma de computador em que ele estiver executando. 

Por fim, se a chamada requer enviar uma mensagem, 
mini_send é chamada (linha 7031), e se for exigido rece¬ 
ber uma mensagem, mini_rec é chamada (linha 7039). 
Essas funções são o coração do mecanismo normal de pas¬ 
sagem de mensagens do minix e merecem estudo cuidado¬ 
so. 

Mini_send (linha 7045) tem três parâmetros: o pro¬ 
cesso que fez a chamada, o processo para o qual enviar e 
um ponteiro para o buffer onde a mensagem está. Ela exe¬ 
cuta vários testes. Primeiro, certifica-se de que os processos 
de usuário tentam enviar mensagens apenas para FS ou 
para MM. Na linha 7060, o parâmetro caller_ptr é testado 
com a macro isuserp para determinar se o processo que fez 
a chamada é um processo de usuário, e o parâmetro dest é 
testado com uma função similar, issysentn, para determi¬ 
nar se é FS ou MM. Se a combinação não for permitida, 
mini_send termina com um erro. 

Em seguida, é feita uma verificação para assegurar que 
o destino da mensagem é um processo ativo, não uma en¬ 
trada vazia na tabela de processos (linha 7062). Nas li¬ 
nhas 7068 a 7073, mini_send verifica se a mensagem cabe 
inteiramente dentro do segmento de dados do usuário, do 
segmento de código ou do intervalo entre eles. Se não, um 
código de erro é retornado 

O próximo teste é verificar um possível impasse. Na li¬ 
nha 7079 há um teste para assegurar que o destino da 
mensagem não está tentando enviar uma mensagem de 
volta ao que fez a chamada. 

0 teste-chave em mini_send está nas linhas 7088 a 
7090. Aqui uma verificação é feita para ver se o destino está 
bloqueado em um rf.CEIYE, como mostrado pelo bit RE- 
CENING no campo p_flags de sua entrada da tabela de 
processos. Se estiver esperando, então, a próxima pergunta 
é: quem ele está esperando?” Se estiver esperando o reme¬ 
tente, ou qualquer outro, CopyMess é executado para copi¬ 
ar a mensagem, e o destinatário é desbloqueado redefinin¬ 
do seu bit RECEMNG. CopyMess é definida como uma 


macro na linha 6932. Ela chama a rotina de linguagem 
assembly cp_mess em klib386.s. 

Se, por outro lado, o destinatário não estiver bloquea¬ 
do, ou estiver bloqueado, mas esperando uma mensagem 
de outro, o código nas linhas 7098 a 7111 é executado para 
bloquear e enfileirar o remetente. Todos os processos que 
estão querendo enviar para um determinado destino são 
enfileirados juntos em uma lista encadeada, com o campo 
p_çallerq do destino apontando para entrada da tabela de 
processos do processo na cabeça da fila. 0 exemplo da Fi¬ 
gura 2-35 (a) mostra o que acontece quando o processo 3 é 
incapaz de enviar para o processo 0. Se subseqüentemente 
o processo 4 também for incapaz de enviar para o processo 
0, obteremos a situação da Figura 2-35(b). 

Mini_rec (linha 6119) é chamada por sys_call quan¬ 
do seu parâmetro function é RECEIVE ou BOTH. 0 laço 
nas linhas 7137 a 7151 pesquisa os processos enfileirados 
que estão esperando enviar para o receptor para ver se qual¬ 
quer um deles é aceitável. Se encontrar algum, a mensa¬ 
gem é copiada do remetente para o receptor; então, o re¬ 
metente é desbloqueado, tornado pronto para executar e 
removido da fila de processos que tentam enviar para o 
receptor. 

Se nenhum remetente conveniente for encontrado, uma 
verificação é feita para ver se o sinalizador p_int_blocked 
do processo do destinatário indica que uma interrupção 
para esse destino foi anteriormente bloqueada (linha 7154). 
Se foi, uma mensagem é criada neste ponto — uma vez 
que as mensagens de HARDWARE não têm nenhum outro 
conteúdo além de HARDWARE no campo de origem e 
ELARDJNT no campo de tipo, não há nenhuma necessida¬ 
de de chamar CopyMess neste caso. 

Se não for encontrada uma interrupção bloqueada, a 
fonte e o endereço do buffer do processo são salvos em sua 
entrada na tabela de processos e ele é marcado como blo¬ 
queado ligando-se seu bit RECEMNG. A chamada a unre- 
ady na linha 7165 remove o destinatário da fila de proces¬ 
sos executáveis do agendador. A chamada é condicional 
para evitar o bloqueio do processo se ainda houvesse outro 
bit ligado em seus/» Jlags; um sinal pode estar pendente, e 
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Figura 2-35 O enfileiramento de processos que tentam enviar para o processo 0. 
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o processo deve ter outra chance de executar logo para tra¬ 
tar do sinal. 

A penúltima declaração em miní_rec (linhas 7171 e 
7172) está relacionada com o modo como os sinais gerados 
pelo kernel SIGINT, SIGQUIT e SIGALRM são gerenciados. 
Quando um desses sinais ocorre, uma mensagem é enviada 
para o gerenciador de memória, se ele estiver esperando uma 
mensagem de ANY. Se não, o sinal é memorizado no kernel 
até que o gerenciador de memória tente, por fim, receber de 
ANY. Isso é testado aqui, e, se necessário, inform é chamado 
para informá-lo dos sinais pendentes. 

2.6.9 Agendamento no MiNix 

0 MiMX utiliza um algoritmo de agendamento de múl¬ 
tiplos níveis que segue bem a estrutura mostrada na Figu¬ 
ra 2-26. Nessa figura, vemos tarefas de E/S na camada 2, 
processos de servidor na camada 3 e processos de usuário 
na camada 4. 0 agendador mantém três filas de processos 
executáveis, um para cada camada, como mostrado na Fi¬ 
gura 2-36. A matriz rdy_head tem uma entrada para cada 
fila, com essa entrada apontando para o processo na cabe¬ 
ça da fila. De maneira semelhante, rdyjail é uma matriz 
cujas entradas apontam para o último processo em cada 
fila. Essas duas matrizes são definidas com a macro EX¬ 
TERN emproe, h (linhas 5192 e 5193) ■ 

Sempre que um processo bloqueado é acordado, ele é 
anexado ao fim de sua fila. A existência da matriz rdyjail 
toma a adicionar um processo ao fim de uma fila uma 
definição eficiente. Sempre que um processo em execução 
torna-se bloqueado, ou um processo executável é elimina¬ 
do por um sinal, esse processo é removido das filas do agen¬ 
dador. Somente processos executáveis são enfileirados. 

Dadas as estruturas de fila que acabamos de descrever, 
o algoritmo de agendamento é simples: encontrar a fila de 
prioridade mais alta que não está vazia e selecionar o pro¬ 
cesso na cabeça dessa fila. Se todas as filas estiverem vazi¬ 
as, a rotina de espera 1 será executada. Na Figura 2-36, 
TASK 0 tem a maior prioridade. 0 código de agendamento 
está emproe, c. A filaé escolhida emptbè j>roc (linha 7179)- 
0 principal trabalho dessa função é configurar proc_ptr. 
Qualquer alteração nas filas, que possa afetar a escolha de 
qual processo deve executar em seguida, requer que 
pick Jroc seja chamada novamente. Sempre que o pro¬ 


cesso atual bloqueia, pick Jroc é chamada para reagen- 
dar a CPU. 

Pick Jroc é simples. Há um teste para cada fila. TASK_Q 
é testada primeiro e se um processo nessa fila estiver pron¬ 
to,/»/^ Jroc configura proc Jtr e imediatamente retor¬ 
na. Em seguida, SERVERJ) é testada, e, novamente, se um 
processo estiver pronto, pick Jroc configura proc Jtr e 
retoma. Se houver um processo pronto na fila USER_Q, 
bill Jtr é alterada para contabilizar ao processo de usuá¬ 
rio o tempo da CPU que está para ser fornecido (linha 7198). 
Isso garante que o último processo de usuário a executar 
seja cobrado pelo trabalho feito em seu benefício pelo sis¬ 
tema. Se nenhuma das filas tem uma tarefa pronta, a li¬ 
nha 7204 transfere a cobrança para o processo !DLE e o 
agenda. 0 processo escolhido para executar não é removi¬ 
do de sua fila meramente porque foi selecionado. 

Os procedimentos ready (linha 7210) e unready (li¬ 
nha 7258) são chamados para colocar um processo execu¬ 
tável em sua fila e remover um processo não mais executá¬ 
vel de sua fila, respectivamente. Ready é chamado tanto a 
partir de mini_send como de mini_rec, como vimos. Ele 
também poderia ter sido chamado a partir de interrupts 
mas, a fim de acelerar o processamento da interrupção, 
seu equivalente funcional foi escrito como parte do código 
de interrupt. Ready manipula uma das três filas de pro¬ 
cessos. Ele simplesmente adiciona o processo ao final da 
fila apropriada. 

Unready também gerencia as filas. Normalmente, o 
processo que ele remove está na cabeça da sua fila, já que 
um processo deve estar executando para ser bloqueado. 
Nesse caso, unready chama pick Jroc antes de retornar, 
como, por exemplo, na linha 7293- Um processo de usuá¬ 
rio que não está executando também pode tomar-se não- 
pronto se ele enviar um sinal e se o processo não for en¬ 
contrado na cabeça de uma das filas, uma pesquisa é feita 
ao longo de USER 0 e ele é removido se for encontrado. 

Embora a maioria das decisões de agendamento seja 
feita quando um processo bloqueia ou desbloqueia, o agen¬ 
damento também deve ser feito quando a tarefa de relógio 
nota que o processo de usuário atual excedeu seu quan- 
tum. Nesse caso, a tarefa de relógio chama sched (linha 
7311) para mover o processo na cabeça de USER_Q para o 
fim dessa fila. Esse algoritmo resulta na execução de pro¬ 
cessos de usuário estritamente no estilo round robin. 0 


Rdy_head Rdyjail 



Figura 2-36 0 agendador mantém três filas, uma por nível de prioridade. 
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sistema de arquivos, o gerenciador de memória e as tarefas 
de E/S nunca são colocados no fim de suas filas porque 
estiveram executando por muito tempo. Confia-se em que 
elas funcionarão adequadamente e bloquearão depois de 
finalizarem seu trabalho. 

Ainda há mais algumas rotinas em proc.c que supor¬ 
tam agendamento de processos. Cinco destas, lock_mini_ 
send. lock_pick_proc, lock_ready. lock_unerady e 
lock_sched. definem um bloqueio, utilizando a variável 
switching antes de chamar a função correspondente e, en¬ 
tão, liberam o bloqueio ao seu término. A última função 
neste arquivo, unhold (linha 7400), foi mencionada em 
nossa discussão sobre _restart em mpx386.s. Ela circula 
pela fila de interrupções suspensas, chamando ínterrupt 
para cada uma, a fim de ter todas as interrupções penden¬ 
tes convertidas em mensagens antes de outro processo ter 
permissão para executar. 

Em resumo, o algoritmo de agendamento mantém três 
filas de prioridade, uma para as tarefas de E/S, uma para 
os processos de servidor e uma para os processos de usuá¬ 
rio. O primeiro processo na fila de prioridade mais alta sem¬ 
pre é executado primeiro. As tarefas e os servidores sempre 
têm permissão para executar até bloquearem, mas a tarefa 
de relógio monitora o tempo utilizado por processos de usu¬ 
ário. Se um processo de usuário utilizar todo seu quan- 
tum, ele é colocado no fim de sua fila, obtendo, assim, um 
agendamento por round vobín simples entre os processos 
de usuário. 

2.6.10 Suporte de Kernel Dependente 
de Hardware 

Há várias funções de C que são muito dependentes do 
hardware. Para facilitar portar o minix para outros siste¬ 
mas, essas funções foram separadas em arquivos que serão 
discutidos nessa seção, exceptíon. c. i8259■ c e protect. c. em 
vez de serem incluídas nos mesmos arquivos com o código 
de nível mais alto que elas suportam. 

Exceptíon. c contém o manipulador de exceções, excep¬ 
tíon (linha7512), queéchamado (como _exception) pela 
parte de linguagem assembly do código de manipulação 
de exceções em mpx386.s. As exceções que se originam de 
processos de usuário são convertidas em sinais. É aceitá¬ 
vel, e até provável, que os usuários cometam erros em seus 
programas, mas uma exceção que se origina no sistema 
operacional indica que algo está seriamente errado e cau¬ 
sa pânico. A matriz ex_data (linhas 7522 a 7540) deter¬ 
mina a mensagem de erro a ser impressa em caso de pâni¬ 
co, ou o sinal a ser enviado para um processo de usuário 
para cada exceção. Os processadores Intel antigos não ge¬ 
ram todas as exceções, e o terceiro campo em cada entrada 
indica o modelo mínimo de processador que é capaz de 
gerar cada uma. Essa matriz fornece um resumo interes¬ 
sante da evolução da família de processadores Intel sobre a 
qual o MINIX foi implementado. Na linha 7563, uma men¬ 
sagem alternativa é impressa se um pânico resulta de uma 
interrupção que não seria esperada do processador em uso. 


As três funções em Í8259.C são utilizadas durante a ini¬ 
cialização do sistema para inicializar os chips controlado¬ 
res de interrupções Intel 8259- Intrjnit (linha 7621) ini¬ 
cializa os controladores. Ela grava dados em várias locali¬ 
zações de porta. Em algumas poucas linhas, uma variável 
derivada dos parâmetros de boot é testada, por exemplo, a 
primeira porta escreve na linha 7637, para acomodar dife¬ 
rentes modelos de computador. Na linha 7638 e novamen¬ 
te na linha 7644, o parâmetro mine é testado e um valor 
apropriado para o minix ou para o BIOS ROM é gravado na 
porta. Ao sair do MINIX, intrjnit pode ser chamada para 
restaurar os vetores de BIOS, oferecendo uma saída ele¬ 
gante para voltar ao monitor de boot. Mine seleciona o 
modo a utilizar. 0 pleno entendimento do que está aconte¬ 
cendo aqui exigiria estudo da documentação do circuito 
integrado 8259 e assim não nos demoraremos nos deta¬ 
lhes. Indicaremos apenas que a chamada ouljbyte na li¬ 
nha 7642 faz o controlador-mestre ignorar qualquer en¬ 
trada exceto a do escravo, e a operação semelhante na li¬ 
nha 7648 inibe a resposta do escravo para todas as suas 
entradas. Além disso, a linha final da função pré-carrega o 
endereço de spuriousjrq, a próxima função no arquivo 
(linha 7657), em cada entrada em irqjable. Isso assegu¬ 
ra que qualquer interrupção gerada antes de os manipula¬ 
dores reais serem instalados não causará nenhum dano. 

A última função em Í8259.C é putJrq_manipulador 
(linha 7673). Na inicialização, cada tarefa que deve res¬ 
ponder a uma interrupção chama essa função para colo¬ 
car seu próprio endereço de manipulador na tabela de in¬ 
terrupção, sobrescrevendo 0 endereço de spuriousjrq. 

Protect.c contém rotinas relacionadas com a operação 
no modo protegido dos processadores Intel. A Tabela Glo¬ 
bal de Descritores ( Global Descriptor Table. GDT), as 
Tabelas Locais de Descritores (Local Descriptor Tables, 
LDTs) e a Tabela de Descritores de Interrupção (ínter¬ 
rupt Descriptor Table. IDT), todas localizadas na memó¬ 
ria, fornecem acesso protegido para recursos do sistema. A 
GDT e a IDT são apontadas por registradores especiais den¬ 
tro da CPU, e as entradas GDT apontam para LDTs. A GDT 
está disponível para todos os processos e armazena descri¬ 
tores de segmento para regiões de memória utilizadas pelo 
sistema operacional. Há normalmente uma I.DT para cada 
processo, que armazena descritores de segmento para as 
regiões de memória utilizadas pelo processo. Os descritores 
são estruturas de 8 bytes com vários componentes, mas as 
partes mais importantes de um descritor de segmento são 
os campos que descrevem 0 endereço de base e 0 limite de 
uma região da memória. A IDT também é composta de 
descritores de 8 bytes, com a parte mais importante sendo 
0 endereço do código a ser executado quando a correspon¬ 
dente interrupção é ativada. 

Protjnit (linha 7767) é chamado por,s7a;7. c para con¬ 
figurar a GDT nas linhas 7828 a 7845. 0 BIOS do IBM PC 
requer que ele seja solicitado de uma certa maneira e todos 
os índices para ele definidos em protect.!:. 0 espaço para 
uma LDT para cada processo é alocado na tabela de pro¬ 
cessos. Cada um contém dois descritores, um para 0 seg- 
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mento de código e um para o segmento de dados — lem¬ 
bre-se de que estamos discutindo aqui os segmentos como 
definidos pelo hardware; que não são os mesmos segmen¬ 
tos gerenciados pelo sistema operacional, o qual considera 
o segmento de dados definido por hardware como dividido 
ainda nos segmentos de dados e de pilha. Nas linhas 7851 
a 7857, são construídos descritores para cada LDT na GDT. 
As funções init_dataseg e init_codeseg realmente criam 
tais descritores. As entradas nas próprias I.DTs são inicia¬ 
das quando um mapa de memória de processo é alterado 
(i. e., quando uma chamada de sistema exec é feita). 

Outra estrutura de dados do processador que precisa de 
inicialização e' o Segmento de Estado de Tarefa (Task 
State Segment, TSS). A estrutura é definida no início desse 
arquivo (linhas 7725 a 7753) e fornece espaço para arma¬ 
zenamento de registradores do processador e de outras in¬ 
formações que devem ser salvas quando uma comutação 
de tarefas é feita. 0 MINIX utiliza apenas os campos que 
definem onde uma nova pilha será criada quando uma 
interrupção ocorrer. A chamada a init_ciataseg na linha 
7867 assegura que ele pode ser localizado utilizando a GDT. 

Para entender como o minix funciona no nível mais 
baixo, talvez a coisa mais importante seja entender como 
exceções, interrupções de hardware ou as instruções int 
<nnn> levam à execução dos vários trechos do código 
que foram escritos para servi-los. Isso é realizado por meio 
da tabela descritora de portão de interrupção. A matriz 
gatejable (linhas 7786 a 7818) é inicializada pelo com¬ 
pilador com os endereços das rotinas que gerenciam exce¬ 
ções e interrupções de hardware e, então, é utilizada no 
laço das linhas 7873 a 7877 para iniciar uma parte grande 
dessa tabela, utilizando chamadas à função int_gate. Os 
vetores restantes ,SYS_VECTOR. SYS386_VEC1X)R eLE\ELO_ 
VECTOR, exigem diferentes níveis de privilégio e são inici- 
alizados depois do laço. 

Há boas razões para o modo como os dados são estru¬ 
turados nos descritores, com base nos detalhes do hardwa¬ 
re e na necessidade de manter compatibilidade entre pro¬ 
cessadores avançados e o processador 286 de 16 bits. Feliz¬ 
mente, em geral, podemos deixar esses detalhes para os 
projetistas de processadores da Intel. Na sua maior parte, a 
linguagem C permite evitar os detalhes. Entretanto, ao 
implementar um sistema operacional real os detalhes de¬ 
vem ser tratados em certa medida. A Figura 2-37 mostra a 
estrutura interna de um tipo de descritor de segmento. Note 


que o endereço de base a que os programas em C podem 
referir-se como um simples inteiro sem sinal de 32 bits, é 
dividido em três partes, duas das quais são separadas em 
porções de 1, 2 e 4 bits. 0 limite é uma quantidade de 20 
bits armazenados como blocos separados de 4 e 16 bits. O 
limite é inteipretado tanto como um número de bytes ou 
um número de páginas de 4096 bytes, baseado no valor do 
bit G (granulanidade). Outros descritores, como os usados 
para especificar como as interrupções são manipuladas, têm 
estruturas diferentes, mas igualmente complexas. Essas es¬ 
truturas serão discutidas com mais detalhes no Capítulo 4. 

A maioria das outras funções definidas em protect.c é 
dedicada a conversão entre variáveis utilizadas em progra¬ 
mas em C e as horríveis formas que esses dados assumem 
nos descritores da máquina como o da Figura 2-37. 
Init_codeseg (linha 7889) e init_dataseg (linha 7906) são 
semelhantes em operação e utilizados para converter os 
parâmetros passados para eles para a forma de descritores 
de segmento. Cada um deles, por sua vez, chama a próxi¬ 
ma função, sdesc (linha 7922), para completar o trabalho. 
Aqui é onde os confusos detalhes da estrutura mostrada na 
Figura 2-37 são tratados. Init_codeseg e init_data_seg não 
são utilizadas apenas na inicialização do sistema. Além 
disso, elas também são chamadas pela tarefa de sistema 
sempre que um novo processo é iniciado para alocar os 
segmentos adequados de memória para uso do processo. 
Seg2phys (linha 7947), chamado apenas a partir de start.c, 
executa uma operação inversa à operação d esdesc. extra¬ 
indo o endereço base de um segmento a partir de um des¬ 
critor de segmento. Int_gate (linha 7969) executa uma 
função semelhante às funções de init_codeseg e init_ 
dataseg na criação de entradas da tabela de descritores de 
interrupções. 

A função final em protect.c, enablejop (linha 7988) 
faz um truque “sujo”. Apontamos em vários lugares que 
uma das funções de um sistema operacional é proteger re¬ 
cursos de sistema, e de certa maneira o minix faz isso utili¬ 
zando níveis de privilégio para certificar-se de que certas 
instruções fiquem fora do alcance de programas de usuá¬ 
rio. Entretanto, o minix também se destina a ser executado 
em sistemas pequenos, que geralmente têm só um usuário 
ou talvez somente alguns usuários com direitos atribuí¬ 
dos. Em um sistema assim, um usuário poderia muito bem 
querer escrever um programa que acessasse portas de E/S, 
por exemplo, para utilizar na aquisição de dados cientffi- 
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cos. 0 sistema de arquivos tem um pequeno segredo cons¬ 
truído nele — quando os arquivos /dev/mem ou /deiZ 
kmem são abertos, a tarefa de memória d\ama.e?iableJop, 
que altera o nível de privilégio para operações de E/S, per¬ 
mitindo que o processo atual execute instruções que lêem 
e gravam em portas de E/S. A descrição do propósito da 
função é mais complicada que a função em si. que apenas 
configura 2 bits, na palavra da estrutura de pilha na entra¬ 
da do processo de chamada, que serão carregados no regis¬ 
trador de status da CPU, quando o processo seguinte for 
executado. Não há nenhuma necessidade de outra função 
desfazer isso, uma vez que se aplicará apenas ao processo 
de chamada. 

2.6.11 Utilitários e Biblioteca do 
Kemel 

Por fim, o kernel tem uma biblioteca de funções de su¬ 
porte escritas em linguagem assembly que são incluídas 
compilando klib.s e alguns programas utilitários, escritos 
em C, no arquivo misc.c. Vejamos primeiro os arquivos de 
linguagem assembly. Klib.s (linha 8000) é um arquivo 
curto semelhante a mpx.s, que seleciona a versão específi¬ 
ca de máquina apropriada com base na definição de 
WORD_S!ZE. 0 código que discutiremos está em klib386.s 
(linha 8100). Ele contém aproximadamente duas dúzias 
de rotinas utilitárias que estão em código assembly. seja 
por eficiência ou porque elas absolutamente não podem 
ser escritas em C. 

_Monitor (linha 8166) possibilita retornar para o mo¬ 
nitor de boot. Do ponto de vista do monitor de boot, todo o 
MiNix é apenas uma sub-rotina e quando o mimx é inicia¬ 
do, um endereço de retomo para o monitor é deixado na 
pilha do monitor. _Monitor precisa apenas restaurar os vá¬ 
rios seletores de segmento e o ponteiro de pilha que foi sal¬ 
vo quando o MINIX foi iniciado, e, então, retornar como de 
qualquer outra sub-rotina. 

A próxima função, _check_mem (linha 8198), é utili¬ 
zada no momento da inicialização para determinar o ta¬ 
manho de um bloco de memória. Ela executa um teste sim¬ 
ples em cada 16 ° byte, utilizando dois padrões que testam 
cada bit com os valores “0" e “1”. 

Embora _phys_copy (veja mais adiante) possa ter sido 
utilizado para copiar mensagens, _cp_mess (linha 8243), 
um procedimento especializado mais rápido, foi fornecido 
para esse propósito. Ele é chamado por 

cp_mess(source, src_clicks, src_offset, dest_clicks, 
dest_offset); 

onde sourceé o número de processo do remetente, o qual é 
copiado no campo m_source do buffer do destinatário. Os 
endereços da origem e do destino são ambos especificados 
fornecendo um número click, em geral, a base do segmen¬ 
to que contém o buffer, e um deslocamento ( offset ) desse 
click. Essa forma de especificar a origem e o destino é mais 
eficiente que os endereços de 32 bits utilizados por 
phys_copy 


_Exit, _ exit e_ exit (linhas 8283 a 8285) são 

definidos porque algumas rotinas de biblioteca que podem 
ser utilizadas ao compilar o mimx fazem chamadas à fun¬ 
ção-padrão exit do C. Uma saída do kernel não é um con¬ 
ceito que faz sentido; não há nenhum lugar para onde ir. A 
solução aqui é ativar as interrupções e entrar em um laço 
interminável. Eventualmente, uma operação de E/S ou o 
relógio acabarão causando uma interrupção, e a operação 
normal do sistema reassumirá. O ponto de entrada para 

_ main (linha 8289) é outra tentativa de lidar com 

uma ação de compilador que, apesar de poder fazer senti¬ 
do ao compilar um programa de usuário, não tem qual¬ 
quer propósito no kernel. Ela aponta para uma instrução 
ret de linguagem assembly (retorno de sub-rotina). 

_ln_byte (linha 8300), _in_ivord (linha 8314), 
_out_byte (linha 8328) e _out_word (linha 8342) forne¬ 
cem acesso a portas de E/S, que no hardware Intel ocupam 
um espaço separado de endereçamento da memória e uti¬ 
lizam instruções diferentes para leitura e para gravação de 
memória. _Port_read (linha 8359 ), _port_read_byte (li¬ 
nha 8386), _J)ort__write (linha8412) e _port_write_byte 
(linha 8439) gerenciam a transferência de blocos de dados 
entre portas de E/S e de memória; eles são utilizados prin¬ 
cipalmente para transferências para e a partir do disco, que 
devem ser feitas mais rapidamente do que é possível com 
outras chamadas de E/S. As versões de byte lêem 8 bits em 
vez de 16 em cada operação para acomodar dispositivos 
periféricos de 8 bits mais antigos. 

Ocasionalmente, uma tarefa precisa desativar todas in¬ 
terrupções de CPU temporariamente. Ela faz isso chaman¬ 
do Jock (linha 8462). Quando as interrupções puderem 
ser reativadas, a tarefa pode chamar _unlock (linha 8474) 
para ativar as interrupções. Uma única instrução de má¬ 
quina executa cada uma dessas operações. Em contraste, o 
código para _Enable_irq (linha 8488) e _disable_irq (li¬ 
nha 8521) é mais complicado. Eles funcionam no nível do 
chip controlador de interrupção para ativar e desativar in¬ 
terrupções de hardware individualmente. 

_Pbys_copy (linha 8564) é chamada em C por 

phys_copy (source_address, destination_address, 
bytes); 

e copia um bloco de dados em qualquer lugar na memória 
física para qualquer outro lugar. Os dois endereços são ab¬ 
solutos, isto é, endereço 0 significa realmente o primeiro 
byte no espaço inteiro de endereçamento, e todos os três 
parâmetros são números inteiros longos sem sinal ( unsig - 
ned longs). 

As duas curtas funções seguintes são muito específicas 
de processadores Intel. _Mem_rdw (linha 8608) retorna 
uma palavra de 16 bits de qualquer lugar na memória. O 
resultado é estendido com zero no registrador de 32 bits 
eax. A função _reset (linha 8623) reinicia o processador. 
Ela faz isso carregando o registrador da tabela de descrito¬ 
res de interrupções do processador com um ponteiro nulo 
e, então, executa uma interrupção de software. Isso tem o 
mesmo efeito que desligar e ligar o hardware. 
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As próximas duas rotinas suportam o monitor de vídeo 
e são utilizadas pela tarefa de console. _Mem_vid_copv 
(linha 8643) copia umzstring de palavras que contém bytes 
de caractere e de atributo alternados, da região da memó¬ 
ria do kernel para a memória do monitor de vídeo. 
_Vid_vid_copy (linha 8696 ) copia um bloco dentro da 
própria memória de vídeo. Isso é um pouco mais compli¬ 
cado, uma vez que 0 bloco de destino pode sobrepor-se ao 
bloco de origem, e a direção do movimento é importante. 

A última função nesse arquivo é JevelO (linha 8773). 
Ela permite que as tarefas tenham 0 nível de permissão de 
maior privilégio, 0 nível zero, quando necessário. Ela é uti¬ 
lizada para coisas como reiniciar a CPU ou acessar as roti¬ 
nas de ROM BIOS do PC. 

Os utilitários de linguagem C em misc.c são especiali¬ 
zados. Mem_in.it (linha 8820) é chamado só por main, 
quando 0 MiNix é inicializado. Pode haver duas ou três re¬ 
giões disjuntas de memória em um computador compatí¬ 
vel com IBM-PC. O tamanho do intervalo mais baixo, co¬ 
nhecido pelos usuários de PC como memória “baixa”, e do 
intervalo de memória que inicia acima da área de ROM do 
PC (memória “estendida”) são informadas pelo BIOS ao 
monitor de boot, que, por sua vez, passa os valores como 
parâmetros de boot , os quais são interpretados por cstart e 
gravados em low_memsize e ext_memsize no momento 
do boot. A terceira região é memória de “sombra”, na qual 
a ROM BIOS pode ser copiada para oferecer uma melhora 
no desempenho, já que a memória ROM é normalmente 
mais lenta que a memória gravável. Como 0 minix nor¬ 
malmente não utiliza 0 BIOS, mem_init tenta localizar 
essa memória e adicioná-la à memória disponível para sua 
utilização. Ele faz isso chamando cbeck_mem para testar 
a região de memória onde essa memória, às vezes, pode ser 
encontrada. 

A próxima rotina, env_parse (linha 8865), também é 
utilizada no momento da inicialização. O monitor de boot 
pode passar strings arbitrárias como “DPETH0=300:10” 
ao MiNix nos parâmetros do boot. Env__parse tenta locali¬ 
zar uma string cujo primeiro campo coincida com seu pri¬ 
meiro argumento, env, e, então, extrai 0 campo requerido. 
Os comentários no código explicam a utilização da fun¬ 
ção. Ela é fornecida principalmente para ajudar 0 usuário 
que quer adicionar novos drivers que podem precisar rece¬ 
ber parâmetros. O exemplo “DPETHO” é utilizado para 
passar informações de configuração a um adaptador Ether¬ 
net quando 0 suporte de rede é compilado no MINIX. 

As duas últimas rotinas que discutiremos neste capítu¬ 
lo são bad_assertion (linha 8935) e bad_compare (linha 
8947). Elas são compiladas só se a macro DEBUG for defi¬ 
nida como TRUE. Elas suportam as macros em assert.h. 
Embora não sejam referenciadas em nenhum código dis¬ 
cutido neste texto, elas podem ser úteis na depuração para 
0 leitor que quer criar uma versão modificada do minix. 


2.7 RESUMO 

Para ocultar os efeitos das interrupções, os sistemas ope¬ 
racionais fornecem um modelo conceituai que consiste de 
processos seqüenciais que executam em paralelo. Os pro¬ 
cessos podem comunicar-se uns com os outros, utilizando 
primitivas de comunicação interprocesso, como semáforos, 
monitores ou mensagens. Essas primitivas também são uti¬ 
lizadas para assegurar que nunca dois processos entrem em 
suas seções críticas ao mesmo tempo. Um processo pode 
estar executando, executável (pronto) ou bloqueado e pode 
mudar de estado quando ele ou outro processo executar uma 
das primitivas de comunicação interprocesso. 

As primitivas de comunicação interprocesso podem ser 
utilizadas para resolver problemas como 0 dos produtores e 
consumidores, 0 dos filósofos jantando, 0 dos leitores-escri¬ 
tores e 0 do barbeiro adormecido. Mesmo com essas primi¬ 
tivas, é preciso tomar cuidado para evitar erros e impasses. 
Muitos algoritmos de agendamento são conhecidos, inclu¬ 
indo round robin , agendamento por prioridade, filas de 
múltiplos níveis e agendadores orientados por política. 

O minix suporta 0 conceito de processo e fornece men¬ 
sagens para a comunicação interprocesso. As mensagens 
não são armazenadas, portanto, um SEND só tem sucesso 
quando 0 destinatário está esperando-o. De maneira seme¬ 
lhante, um RECEIVE só tem sucesso quando uma mensa¬ 
gem já está disponível. Se qualquer uma dessas operações 
não é bem-sucedida, 0 processo que fez a chamada é blo¬ 
queado. 

Quando uma interrupção ocorre, 0 nível mais baixo do 
kernel cria e envia uma mensagem à tarefa associada com 
0 dispositivo de interrupção. Por exemplo, a tarefa de disco 
chama receive e é bloqueada depois de gravar um coman¬ 
do no hardware controlador de disco requisitando a leitura 
de um bloco de dados. 0 hardware do controlador gera uma 
interrupção quando os dados estão prontos. 0 software de 
baixo nível, então, cria uma mensagem para a tarefa de 
disco e marca-a como executável. Quando 0 agendador es¬ 
colhe a tarefa de disco a executar, ela recebe e processa a 
mensagem. Também é possível que 0 manipulador de in¬ 
terrupção faça algum trabalho diretamente, como uma 
interrupção de relógio para atualizar a hora. 

A comutação de tarefas pode seguir-se a uma interrup¬ 
ção. Quando um processo é interrompido, uma pilha é cri¬ 
ada dentro da entrada do processo na tabela de processos e 
todas as informações necessárias para reiniciá-la são colo¬ 
cadas na nova pilha. Qualquer processo pode ser reinicia¬ 
do configurando 0 ponteiro de pilha para apontar para sua 
entrada de tabela de processos e iniciando uma seqüência 
de instruções a fim de restaurar os registradores de CPU, 
culminando com uma instrução iretd. 0 agendador deci¬ 
de qual entrada da tabela de processos colocar no ponteiro 
da pilha. 
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Interrupções também ocorrem quando o próprio ker- 
nel está executando. A CPU detecta isso, e a pilha do ker- 
nel, em vez de uma pilha dentro da tabela de processos, é 
utilizada. Assim interrupções aninhadas podem ocorrer e 
quando uma rotina de serviço de interrupção posterior ter¬ 
mina, a anterior pode completar-se. Quando todas as inter¬ 
rupções foram servidas, um processo é reiniciado. 


0 algoritmo de agendamento do luxix utiliza três filas 
de prioridade, a mais alta para tarefas, a próxima para o 
sistema de arquivos, o gerenciador de memória e outros ser¬ 
vidores, se houver algum, e a mais baixa para processos de 
usuário. Os processos de usuário são executados em round 
robin pelo tempo de um quantum por vez. Todos os demais 
são executados até que bloqueiem ou sofram preempção. 


EXERCÍCIOS 


1. Suponha que você vá projetar uma arquitetura avançada de 
computador que faz a comutação de processos em hardwa¬ 
re, em vez de ter interrupções. Que informações a CPU preci¬ 
saria? Descreva como a comutação de processos por hardware 
pode funcionar. 

2 . Hm todos computadores atuais, pelo menos parte dos mani¬ 
puladores de interrupções são escritos em linguagem assem- 
bly. Por quê? 

3. No texto, afirmou-se que o modelo da Figura 2-6(a) não se 
ajustava a um servidor de arquivos utilizando um cache em 
memória. Por que não? Cada processo poderia ter seu pró¬ 
prio cache ? 

4. Em um sistema com tbreads, há uma pilha por thread ou 
uma pilha por processo? Explique. 

5 . 0 que é uma condição de corrida? 

6. Escreva um script de shell que produz um arquivo de núme¬ 
ros seqüenciais lendo o último número no arquivo, adicio¬ 
nando 1 a ele e, então, anexando o resultado ao arquivo. 
Execute uma instância do script em segundo plano e uma 
em primeiro plano, cada uma acessando o mesmo arquivo. 
Quanto tempo se passa antes de uma condição de corrida 
manifestar-se? Qual é a seção crítica? Modifique o script para 
evitar a condição de corrida (sugestão: utilize 

In file file.lock 

para bloquear o arquivo de dados). 

7. Uma declaração como 
In file file.lock 

é um mecanismo de bloqueio efetivo para um programa de 
usuário como os scripts utilizados no problema anterior? 
Por quê (ou por que não)? 

8 . A solução da espera ativa utilizando a variável turn (Figura 
2-8) funciona quando os dois processos estão executando 
em um multiprocessador com memória compartilhada, isto 
é, duas CPUs compartilhando uma memória comum? 

9. Considere um computador que não tem uma instrução TEST 
AND SET LOCK mas tem uma instrução para comutar conteú¬ 
do de um registrador e de uma palavra da memória em uma 
única ação indivisível. É possível utilizar isso para escrever 
uma rotina enter_region como a encontrada na Figura 2- 
10 ? 


10. Faça um esboço de como um sistema operacional que pode 
desativar interrupções poderia implementar semáforos. 

11. Mostre como semáforos de contagem (i. e., semáforos que 
podem armazenar um valor arbitrariamente grande) podem 
ser implementados utilizando apenas semáforos binários e 
instruções comuns de máquina. 

12. Na Seção 2.2.4, foi descrita uma situação com um processo 
de alta prioridade, H, e um processo de baixa prioridade, L, 
que levou a um laço eterno de //. 0 mesmo problema ocorre 
se o agendamento por round robin for utilizado em vez de 
agendamento por prioridade? Discuta. 

13. A sincronização dentro de monitores utiliza variáveis de con¬ 
dição e duas operações especiais wait e signal Uma forma 
mais geral de sincronização seria ter uma única primitiva 
WAITUNTIL que tivesse um predicado booleano arbitrário 
como parâmetro. Portanto, poderia dizer-se. por exemplo, 

WAITUNTIL.v < 0 orj + z <n 

A primitiva SIGNAL não seria mais necessária. Esse esquema 
é claramente mais geral que o de Hoare ou Brinch Hansen, 
mas não é utilizado. Por que não? (Sugestão: pense na im¬ 
plementação.) 

14. Um restaurante fastfood tem quatro tipos de empregados: 
(1) os atendentes, que anotam os pedidos dos clientes; (2) 
os cozinheiros, que preparam o alimento; (3) os embalado- 
res, que colocam o alimento em sacolas; (4) os caixas, que 
entregam as sacolas aos clientes e recebem o dinheiro. Cada 
empregado pode ser considerado como um processo de co¬ 
municação seqüencial. Que forma de comunicação inter- 
processo eles utilizam? Relacione esse modelo com proces¬ 
sos no MINIX. 

15. Suponha que temos um sistema de passagem de mensagens 
utilizando caixas de correio. Ao enviar para uma caixa de 
correio cheia ou ao tentar receber de uma vazia, um proces¬ 
so não é bloqueado. Em vez disso, ele recebe de volta um 
código de erro. 0 processo responde ao código de erro ape¬ 
nas tentando novamente, repetidamente, até ter sucesso. Esse 
esquema leva a condições de corrida? 

16. Na solução para o problema dos filósofos jantando (Figura 
2-20), por que a variável de estado é configurada como 
HUNGRY no procedimento take Jorks? 
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17. Considere o procedimento/?/// _forks na Figura 2-20. Supo¬ 
nha que a variável state[i] tenha sido configurada como 
THINK1NG após as duas chamadas a test, em vez de antes. 
Como essa alteração afetaria a solução para o caso de três 
filósofos? E para 100 filósofos? 

18. O problema dos leitores e dos escritores pode ser formulado 
de várias maneiras com referência a qual categoria de pro¬ 
cessos pode ser iniciada e quando ela pode ser iniciada. Cui¬ 
dadosamente. descreva três variações diferentes do proble¬ 
ma, cada uma favorecendo (ou não) alguma categoria de 
processos. Para cada variação, especifique o que acontece 
quando um leitor ou um escritor torna-se pronto para aces¬ 
sar o banco de dados e o que acontece quando um processo 
termina de utilizar o banco de dados. 

19- Os computadores CDC 6600 podiam gerenciar ate' 10 pro¬ 
cessos de E/S simultaneamente utilizando uma forma inte¬ 
ressante de agendamento por round robin chamada com¬ 
partilhamento do processador. Uma comutação de pro¬ 
cessos ocorria depois de cada instrução, assim a instrução 1 
vinha do processo 1, a instrução 2 vinha do processo, 2 etc. A 
comutação de processos era feita por hardware especial e o 
acréscimo ( orerhead) era zero. Se um processo precisasse 
de Ts para completar-se na ausência de concorrência, quanto 
tempo precisaria se o compartilhamento do processador fosse 
utilizado com n processos? 

20. Os agendadores por round robin normalmente mantêm 
uma lista de todos os processos executáveis, com cada pro¬ 
cesso ocorrendo exatamente uma vez na lista. O que aconte¬ 
ceria se um processo ocorresse duas vezes na lista? Você con¬ 
segue imaginar qualquer razão para permitir isto? 

21. Medidas de um certo sistema mostraram que, na média, as 
execuções dos processos tendiam para um tempo T antes de 
bloquear em E/S. Uma comutação de processos requer um 
tempo S, que é efetivamente desperdiçado (orerhead). Para 
agendamento por round robin com quantum Q, dê uma 
fórmula da eficiência de CPU para cada um dos seguintes, 

(a) Q = a 

(B) Q >T 

(c) S < Q <T 

(d) Q = S 

(e) Q perto de 0 

22. Cinco jobs estão esperando para ser executados. Seus tem¬ 
pos esperados de execução são 9,6, 3, 5 e A". Em que ordem 
eles devem ser executados para minimizar tempo médio de 
resposta? (Sua resposta dependerá de.v. ) 

23- Cinco jobs de lote,/l até E, chegam a um centro de compu¬ 
tação quase ao mesmo tempo. Eles têm tempos de execução 
estimados de 10,6, 2,4e 8 minutos. Suas prioridades (exter¬ 
namente determinadas) são 3. 5, 2, 1 e 4, respectivamente, 
com 5 sendo a maior prioridade. Para cada um dos seguin¬ 
tes algoritmos de agendamento, determine o tempo de re¬ 
torno médio dos processos. Ignore o acréscimo (orerhead) 
da comutação de processos. 

(a) Round robin. 

(b) Agendamento por prioridade. 

(c) Primeiro a chegar, primeiro a ser servido (execução 
na ordem 10, 6, 2,4, 8). 

(d) Job mais curto primeiro. 


Para (a), suponha que o sistema é multiprogramado e que 
ciàijob receba sua justa parte da CPU. Para (b) a (d) supo¬ 
nha que só um job execute por vez, até terminar. Todos os 
jobs são completamente associados à CPU. 

24. Um processo que executa no CTSS precisa de 30 quanta para 
completar-se. Quantas vezes ele deve sofrer comutação, in¬ 
cluindo a primeira vez (antes de ele executar completamen¬ 
te)? 

25- O algoritmo de envelhecimento com a = 1/2 está sendo uti¬ 
lizado para prever tempos de execução. As quatro execuções 
anteriores, da mais antiga à mais recente, foram 40,20,40 e 
15ms. Qual é a previsão do próximo tempo? 

26. Um sistemasq/? real time tem quatro eventos periódicos com 
períodos de 50,100,200 e 250ms cada. Suponha que os qua¬ 
tro eventos requeiram 35, 20, 100 e.v ms de tempo de CPU, 
respectivamente. Qual é o maior valor de ,v para o qual o 
sistema é agendável? 

27. Explique por que o agendamento de dois níveis é comumente 
utilizado. 

28. Durante execução, o mintx mantém uma variável proc_ptr 
que aponta para entrada da tabela de processos para o pro¬ 
cesso atual. Por quê? 

29- O MINIX não armazena mensagens. Explique como essa de¬ 
cisão de projeto causa problemas com interrupções de reló¬ 
gio e teclado. 

30. Quando uma mensagem é enviada a um processo adorme¬ 
cido no MINIX, o procedimento ready é chamado para colo¬ 
car esse processo na fila adequada de agendamento. Esse 
procedimento inicia desativando as interrupções. Explique. 

31- O procedimento do MINIX mini_rec contém um laço. Expli¬ 
que para que ele serve. 

32. Essencialmente o minix utiliza o método de agendamento 
na Figura 2-23, com prioridades diferentes para classes. A 
classe mais baixa (processos de usuário) tem agendamento 
por round robin, mas as tarefas e os servidores sempre têm 
pemiissão para executar até bloquearem. É possível que pro¬ 
cessos na classe mais baixa morram de fome? Por quê (ou 
por que não)? 

33. O MINIX é adequado para aplicativos de tempo real, como 
registro de dados? Se não, o que poderia ser feito para torná- 
lo adequado? 

34. Suponha que você tenha um sistema operacional que forne¬ 
ça semáforos. Implemente um sistema de mensagens. Escre¬ 
va os procedimentos para enviar e para receber mensagens. 

35. Um aluno forte em Antropologia, mas fraco em Ciência da 
Computação envolveu-se em um projeto de pesquisa para 
verificar se babuínos africanos podem ser ensinados sobre 
impasses. Ele encontrou um desfiladeiro e amarrou uma 
corda através dele, de modo que os babuínos pudessem cru¬ 
zá-lo utilizando a corda. Vários babuínos podem cruzar o 
desfiladeiro ao mesmo tempo, desde que todos sigam na 
mesma direção. Se os babuínos utilizarem a corda para cru¬ 
zar o desfiladeiro de leste para oeste e de oeste para leste ao 
mesmo tempo, o resultado será um impasse (os babuínos 
ficarão presos no meio) porque é impossível um babuíno 
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subir sobre outro enquanto suspenso sobre o desfiladeiro. Se 
um babuíno quiser cruzar o desfiladeiro, ele deve verificar 
se nenhum outro está atualmente cruzando na direção opos¬ 
ta. Escreva um programa, utilizando semáforos, que evite o 
impasse. Não se preocupe com uma série de babuínos que se 
move para leste segurando indefinidamente babuínos que 
se movem para o oeste. 

36. Repita o problema anterior, mas agora evite a fome. Quan¬ 
do um babuíno que quiser cruzar para o leste chegar à cor¬ 
da e encontrar babuínos cruzando para o oeste, ele espera 
até que a corda estej a vazia, mas os babuínos que se movem 
para o oeste não mais são permitidos a iniciar até que pelo 
menos um babuíno tenha cruzado para o outro lado. 

37. Resolva o problema dos filósofos jantando utilizando moni¬ 
tores em vez de semáforos. 


38. Adicione código ao keniel do minix para monitorar o nú¬ 
mero de mensagens enviadas a partir do processo (ou tare¬ 
fa) i ao processo (ou tarefa)/ Imprima essa matriz quando 
a tecla F4 for pressionada. 

39- Modifique o agendador do minix para monitorar o tempo de 
CPU que cada processo de usuário teve recentemente. Quan¬ 
do nenhuma tarefa ou servidor quiser executar, selecione o 
processo de usuário que teve a menor porção da CPU. 

40. Reprojete o minix de tal modo que cada processo tenha um 
campo de nível prioridade em sua tabela de processos que 
possa ser utilizado para dar prioridades mais altas ou mais 
baixas a processos individuais. 

41. Modifique as macros huint_master e bwint_slave em 
mpx386.s para que as operações agora realizadas pela fun¬ 
ção sane sejam executadas inline. Qual é o custo em termos 
do tamanho do código? Você pode medir um aumento no 
desempenho? 



3 


Entrada/Saída 


Uma das principais funções de um sistema operacional 
é controlar todos os dispositivos de E/S (Entrada/Saída). 
Ele deve enviar comandos para os dispositivos, capturar 
interrupções e tratar erros. Também deve oferecer uma in¬ 
terface entre os dispositivos e o restante do sistema que seja 
simples e fácil de usar. Na medida do possível, a interface 
deve ser a mesma para todos os dispositivos (independên¬ 
cia de dispositivo). 0 código de E/S representa uma fração 
significativa do total do sistema operacional. 

A maneira como o sistema operacional gerencia E/S é 
o assunto deste capítulo, cuja visão geral é apresentada a 
seguir. 

Primeiro veremos um resumo sobre alguns princípios 
de hardware de E/S e, então, veremos software de E/S que, 
em geral, pode ser estruturado em camadas, com cada ca¬ 
mada tendo uma tarefa bem definida a executar. Estuda¬ 
remos essas camadas para ver o que elas fazem e como seu 
conjunto é organizado. 

Logo após, vem uma seção sobre impasses ( deadlocks ). 
Definiremos impasses precisamente, mostrando como são 
causados, oferecendo dois modelos para analisá-los e dis¬ 
cutindo alguns algoritmos para prevenir sua ocorrência. 
Então, daremos uma rápida olhada em E/S no MINIX. Se- 
guindo-se a essa introdução, veremos quatro dispositivos 
de E/S em detalhes — o disco de RAM, o disco rígido, o 
relógio e o terminal. Para cada dispositivo, estudaremos 
seu hardware, seu software e implementação no MINIX. Por 
fim, o capítulo fecha com uma breve discussão sobre uma 
pequena parte do MINIX que está localizada na mesma ca¬ 
mada que as tarefas de E/S, mas que não é propriamente 
uma tarefa de E/S. Ela oferece alguns serviços para o ge¬ 
renciador de memória e para o sistema de arquivos, como 
buscar blocos de dados de um processo de usuário. 


3.1 PRINCÍPIOS DE HARDWARE DE E/S 

Pessoas diferentes vêem o hardware de E/S de maneiras 
diferentes. Engenheiros elétricos vêem-no em termos de 
chips, de fios, de fontes de alimentação, de motores e de 
todos os outros componentes físicos que o constituem. Os 
programadores vêem a interface apresentada para o sof¬ 
tware — os comandos que o hardware aceita, as funções 
que ele executa e os erros que podem ser retornados. Neste 
livro, estamos preocupados com a programação de dispo¬ 
sitivos de E/S, não como projetar, como construir ou como 
mantê-los, portanto nosso interesse irá restringir-se ao modo 
como o hardware é programado, não como ele funciona 
por dentro. Contudo, a programação de dispositivos de E/S 
com freqüência está intimamente associada com sua ope¬ 
ração interna. Nas próximas três seções, ofereceremos uma 
breve fundamentação sobre hardware de E/S no que diz 
respeito à programação. 

3.1.1 Dispositivos de E/S 

Os dispositivos de E/S podem ser divididos, grosso modo, 
em duas categorias: dispositivos de bloco e dispositi¬ 
vos de caractere. Um dispositivo de bloco armazena in¬ 
formações em blocos de tamanho fixo, cada um com seu 
próprio endereço. Os tamanhos de bloco comuns variam 
de 512 a 32.768 bytes. A propriedade essencial de um dis¬ 
positivo de bloco é que é possível ler ou gravar cada bloco 
independentemente de todos os outros. Os discos são os dis¬ 
positivos de bloco mais comuns. 

Se você olhar de perto, verá que não é bem definida a 
divisão entre dispositivos que são endereçáveis por blocos 
e aqueles que não são. Todo o mundo concorda que um 
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disco é um dispositivo endereçável por blocos, porque, in¬ 
dependentemente de onde o braço está atualmente, sem¬ 
pre é possível buscar outro cilindro e, então, esperar o blo¬ 
co requisitado passar sob o cabeçote. Agora considere uma 
unidade de fita DAT ou de 8 mm utilizada para fazer ba- 
ckups de disco. Suas fitas geralmente contêm blocos de ta¬ 
manho fixo. Se a unidade de fita receber um comando para 
ler o bloco N, ela pode sempre retroceder e avançar a fita 
até chegar ao bloco A 7 . Essa operação é análoga a um disco 
fazendo uma busca, exceto que toma muito mais tempo. 
Além disso, pode ou não ser possível regravar um bloco no 
meio de uma fita. Mesmo que fosse possível utilizar fitas 
como dispositivos de bloco de acesso aleatório, isso ultra¬ 
passaria um tanto o limite estabelecido: elas normalmente 
não são utilizadas assim. 

O outro tipo de dispositivo de E/S é o dispositivo de ca¬ 
ractere, o qual entrega ou aceita um fluxo de caracteres, 
sem considerar qualquer estrutura de bloco. Ele não é en¬ 
dereçável e tampouco tem qualquer operação de busca. As 
impressoras, interfaces de rede, mouses (para apontar), 
ratos (para experiências de laboratório de Psicologia) e a 
maioria dos outros dispositivos que não são do tipo disco 
podem ser vistas como dispositivos de caractere. 

Esse esquema de classificação não é perfeito. Alguns 
dispositivos simplesmente não se ajustam nele. Os relógi¬ 
os, por exemplo, não são endereçáveis por bloco. Tampou¬ 
co eles geram ou aceitam fluxos de caractere. Tudo que 
fazem é gerar interrupções em intervalos bem definidos. As 
telas mapeadas em memória também não se ajustam ao 
modelo. De qualquer modo, o modelo de dispositivos de 
bloco e de caractere é suficientemente geral para que possa 
ser utilizado como uma base para construir, de forma in¬ 
dependente de dispositivo, algumas partes do sistema ope¬ 
racional que tratam de E/S. O sistema de arquivos, por 
exemplo, lida apenas com dispositivos de bloco abstratos e 
deixa a parte dependente do dispositivo para o software de 
baixo nível chamado drivers de dispositivo. 

3-1.2 Controladoras de Dispositivo 

As unidades de E/S geralmente consistem em um com¬ 
ponente mecânico e em outro eletrônico. Freqüentemente 
é possível separar as duas partes para oferecer um projeto 


mais modular e genérico. O componente eletrônico é cha¬ 
mado controladora ou adaptador de dispositivo. Em 

computadores pessoais, esse freqüentemente toma a forma 
de uma placa de circuito impresso que pode ser inserida 
em um slot na parentboard do computador (antes incor¬ 
retamente chamada de motherboard, placa-mãe). 0 com¬ 
ponente mecânico é o dispositivo em si. 

A placa controladora normalmente tem nela um co¬ 
nector, onde um cabo que leva ao dispositivo em si pode ser 
conectado. Muitas controladoras podem manipular, qua¬ 
tro ou até oito dispositivos idênticos. Se a interface entre a 
controladora e o dispositivo é uma interface-padrão, seja 
um dos padrões oficiais como ANSI, IEEE ou ISO ou um 
padrão de fato, então as empresas podem fazer controla¬ 
doras ou dispositivos que se ajustam a essa interface. Mui¬ 
tas empresas, por exemplo, fazem unidades de disco que se 
ajustam aos padrões de interfaces controladoras de disco 
IDE {IntegratedDrive Electronics) ou SCSI (Small Com¬ 
puter A) ■stem Interface). 

Mencionamos essa distinção entre controladora e dis¬ 
positivo porque o sistema operacional quase sempre lida 
com a controladora, não com o dispositivo. A maioria dos 
pequenos computadores utiliza o modelo de barramento 
único da Figura de 3-1 para comunicação entre a CPU e as 
controladoras. Mainframe s freqüentemente utilizam um 
modelo diferente, com múltiplos barramentos e computa¬ 
dores especializados de E/S, chamados canais de E/S que 
assumem parte da carga da CPU principal. 

A interface entre a controladora e o dispositivo é fre¬ 
qüentemente uma interface de muito baixo nível. Um dis¬ 
co, por exemplo, talvez seja formatado com 16 setores de 
512 bytes por trilha. Entretanto, o que realmente sai da j 
unidade é um fluxo serial de bits, iniciando com um pre- j 
âmbulo, depois os 4096 bits em um setor e por fim uma j 
soma de verificação, também chamada Código para Cor- j 
reção de Erros — ECC (Error-Correcting Code). 0 
preâmbulo é gravado quando o disco é formatado e con- j 
tém o cilindro e o número de setor, o tamanho do setor e j 
dados semelhantes, assim como as informações de sincro- j 
nização. ; 

O trabalho da controladora é converter o fluxo serial de j 
bits em um bloco de bytes e executar qualquer correção de j 
erro necessária. O bloco de bytes tipicamente é primeiro j 
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Figura 3-1 Um modelo para conectar CPU, memória, controladoras e dispositivos de E/S. 
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montado, bit por bit, em um buffer dentro da controlado¬ 
ra. Depois que sua soma de verificação foi verificada e o 
bloco foi declarado livre de erros, ele pode, então, ser copi¬ 
ado para a memória principal. 

A controladora para um terminal CRT também funcio¬ 
na como um dispositivo serial de bits em um nível igual- 
mente baixo. Ela lê da memória bytes que contêm os ca¬ 
racteres a serem exibidos e gera os sinais utilizados para 
modular o feixe do CRT a fim de fazê-lo escrever na tela. A 
controladora também gera os sinais para instruir o feixe 
do CRT a fazer um retraço horizontal depois de ele acabar 
uma linha de varredura, bem como os sinais para instruí- 
lo a fazer um retraço vertical depois que a tela inteira foi 
varrida. Se isso não fosse feito pela controladora do CRT, o 
programador do sistema operacional teria de programar 
explicitamente uma varredura análoga para o tubo. Com 
a controladora, o sistema operacional inicia a controlado¬ 
ra com alguns parâmetros, como o número de caracteres 
por linha e número de linhas por tela e deixa a controla¬ 
dora encarregada de realmente guiar o feixe. 

Cada controladora tem alguns registradores que são 
utilizados para comunicar-se com a CPU. Em alguns com¬ 
putadores, esses registradores são parte do espaço normal 
de endereçamento de memória. Esse esquema é chamado 
E/S mapeada em memória. 0 680x0, por exemplo, utili¬ 
za esse método. Outros computadores utilizam um espaço 
especial de endereçamento para E/S, com cada controla¬ 
dora alocando uma certa parte dele. A atribuição de ende¬ 
reços de E/S para dispositivos é feita pela lógica de decodi- 
ficação de barramento associada com a controladora. Al¬ 
guns fabricantes dos chamados compatíveis com IBM PC 
utilizam endereços diferentes de E/S diferentes daqueles 
usados pela IBM. Além de portas de E/S, muitas controla¬ 
doras utilizam interrupções para informar à CPU quando 
estão prontas para ter seus registradores lidos ou gravados. 
Uma interrupção é, em primeiro lugar, um evento elétrico. 
Uma linha de solicitação de interrupção de hardware (IRQ 
— Interrupt ReQuest) é uma entrada física para o chip 
controlador de interrupções. O número dessas entradas é 
limitado; PCs da classe Pentium têm somente 15 disponí¬ 
veis para dispositivos de E/S. Algumas controladoras são 
conectadas diretamente ( hard-wired) à placa-mãe do sis¬ 
tema, como é, por exemplo, a controladora de teclado de 
um IBM PC. No caso de uma controladora que se conecta 
ao backplane ,' às vezes, podem ser utilizados switches ou 
jumpers na controladora de dispositivo para selecionar a 
IRQ que o dispositivo utilizará, a fim de evitar conflitos 
(embora em algumas placas, como as Plug and Play , as 
IRQs possam ser configuradas por software). O chip con¬ 
trolador de interrupções mapeia cada entrada de IRQ para 


*N. de T. Uma placa ou uma estrutura de circuitos que suporta outras 
placas de circuitos, dispositivos e as interconexões entre os dispositivos, 
e fornece energia e sinais de dados aos dispositivos suportados. (Dicio¬ 
nário de Informática. Microsoft Press. Rio de Janeiro, Editora Cam¬ 
pus, 1998.) 


um vetor de interrupção, que localiza o correspondente 
software de serviço de interrupção. A Figura 3-2 mostra os 
endereços de E/S, as interrupções de hardware e o vetor de 
interrupção atribuídos a algumas controladoras em um 
IBM PC, a título de exemplo. O xnxix utiliza as mesmas 
interrupções de hardware, mas o vetores de interrupção do 
Mixix são diferentes desses mostrados aqui para MS-DOS. 

O sistema operacional executa E/S gravando coman¬ 
dos nos registradores da controladora. A controladora de 
disquetes do IBM PC, por exemplo, aceita 15 comandos di¬ 
ferentes, como READ, WRITE, SEEK, FORMAT e RECAI.IBRATE. 
Muitos dos comandos têm parâmetros, que também são 
carregados nos registradores da controladora. Quando um 
comando é aceito, a CPU pode deixar a controladora con¬ 
tinuar sozinha e ir fazer outro trabalho. Quando o coman¬ 
do é completado, a controladora gera uma interrupção para 
permitir que o sistema operacional ganhe controle da CPU 
e teste os resultados da operação. A CPU obtém os resulta¬ 
dos e o status do dispositivo lendo um ou mais bytes de 
informações dos registradores da controladora. 

3-1.3 Acesso Direto à Memória (DMA) 

Muitas controladoras, especialmente as de dispositivos 
de bloco, suportam Acesso Direto à Memória ou DMA 
(Direct Memory Access) . Para explicar como o DMA fun¬ 
ciona vejamos primeiro como as leituras de disco ocorrem 
quando o DMA não é utilizado. Primeiro a controladora lê 
o bloco (um ou mais setores) da unidade serialmente, bit a 
bit, até que o bloco inteiro esteja no buffer interno da con¬ 
troladora. Em seguida, ela calcula a soma de verificação 
para certificar-se de que não ocorreram erros de leitura. 
Então, a controladora gera uma interrupção. Quando o sis¬ 
tema operacional começa a executar, ele pode ler o bloco 
de disco do buffer da controladora, um byte ou uma pala¬ 
vra por vez executando um laço, com cada iteração lendo 
um byte ou uma palavra de um registrador da controlado¬ 
ra de dispositivo e armazenando-o na memória. 

Naturalmente, um laço programado para ler os bytes 
um por vez a partir da controladora desperdiça tempo da 
CPU. O DMA foi inventado para liberar a CPU desse traba¬ 
lho de baixo nível. Quando é utilizado, a CPU fornece dois 
itens de informação para a controladora, além do endere¬ 
ço do bloco no disco: o endereço de memória para onde o 
bloco deve ir e o número de bytes a transferir, como mos¬ 
trado na Figura 3-3- 

Depois que a controladora leu o bloco inteiro do dispo¬ 
sitivo para seu buffer e verificou a soma de verificação, ela 
copia o primeiro byte ou palavra para o endereço na me¬ 
mória principal especificado pelo endereço de memória 
DMA. Então, ela incrementa o endereço de DMA e decre- 
menta a contagem do DMA pelo número de bytes que aca¬ 
bou de transferir. Esse processo é repetido até que a conta¬ 
gem de DMA torne-se zero, momento em que a controla¬ 
dora gera uma interrupção. Quando o sistema operacional 
inicia, ele não precisa copiar o bloco para a memória; ele 
já está lá. 
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Controladora de E/S 

Endereço de E/S 

IRQ de hardware 

Vetor de interrupção 

Relógio 

040 - 043 

0 

8 

Teclado 

060 - 063 

1 

9 

Disco rígido 

1F0-1F7 

14 

118 

RS232 secundário 

2F8-2FF 

3 

11 

Impressora 

378 - 37F 

7 

15 

Disquete 

3F0 - 3F7 

6 

14 

RS232 primário 

3F8 - 3FF 

4 

12 


Figura 3-2 Alguns exemplos de controladoras, seus endereços de E/S, suas linhas de interrupção de hardware e seu 
vetor de interrupção em um PC típico rodando MS-DOS. 


Você pode estar perguntando-se por que a controladora 
simplesmente não armazena os bytes na memória princi¬ 
pal logo que os recebe do disco. Em outras palavras, por 
que ela precisa de um buffer interno? A razão é que uma 
vez que a transferência de disco iniciou, os bits continuam 
chegando do disco a uma taxa constante, esteja a contro¬ 
ladora pronta para eles ou não. Se a controladora tentasse 
gravar dados diretamente na memória, ela teria de passar 
pelo barramento de sistema para cada palavra transferida. 
Se o barramento estivesse ocupado devido a algum outro 
dispositivo que o estivesse utilizando, a controladora teria 
de esperar. Se a próxima palavra do disco chegasse antes 
que a anterior tivesse sido armazenada, a controladora te¬ 
ria de armazená-la em algum lugar. Se o barramento esti¬ 
vesse muito ocupado, a controladora talvez acabasse ar¬ 
mazenando muitas palavras e teria muita administração 
a fazer também. Quando o bloco é bufferizado interna¬ 
mente, o barramento não é necessário até que o DMA ini¬ 
cie; então, o projeto da controladora é muito mais simples 
porque a transferência via DMA para a memória não é uma 
tarefa dependente do tempo. (Algumas controladoras mais 
velhas iam, de fato, diretamente para memória com ape¬ 
nas um pequeno buffer interno, mas quando o barramen¬ 
to estava muito ocupado, uma transferência poderia preci¬ 
sar ser terminada com um erro de overrun .*) 

0 processo de bufferização em duas etapas descrito 
acima tem implicações importantes para o desempenho 
de E/S. Enquanto os dados estão sendo transferidos da con¬ 
troladora para a memória, seja pela CPU ou pela controla¬ 
dora, o próximo setor estará passando sob o cabeçote do 
disco, os bits estarão chegando na controladora. Controla¬ 
doras mais simples não conseguem fazer presente a entra¬ 
da e a saída simultâneas, então, enquanto uma transfe- 


'N. de T. Na transferência de informações, um erro que ocorre quando 
um dispositivo receptor não consegue tratar ou utilizar os dados com a 
mesma rapidez com que são enviados. (Dicionário de Informática. 
Microsoft Press. Rio de Janeiro, Editora Campus, 1998.) 


rência de memória está acontecendo, o setor que passa sob 
o cabeçote do disco é perdido. 

Como resultado, a controladora somente será capaz de 
ler blocos alternados. A leitura de uma trilha completa, 
então, exigirá duas rotações completas, uma para os blo¬ 
cos pares e uma para os blocos ímpares. Se o tempo de 
transferir um bloco da controladora para a memória pelo 
barramento for mais longo que o tempo de ler um bloco do 
disco, pode ser necessário ler um bloco e, então, pular dois 
(ou mais) blocos. 

A técnica de saltar blocos a fim de dar tempo para a 
controladora transferir dados para a memória é chamada 
intercalação {interleaving). Quando o disco é formata¬ 
do, os blocos são numerados para tomar conta do fator de 
intercalação. Na Figura 3-4(a) vemos um disco com 8 blo¬ 
cos por trilha e nenhuma intercalação. Na Figura 3-4(b) 
vemos o mesmo disco com uma única intercalação. Na 
Figura 3-4 (c), a intercalação dupla é mostrada. 

A idéia de numerar os blocos dessa maneira é para per¬ 
mitir que o sistema operacional leia os blocos consecutiva¬ 
mente numerados e ainda alcance a taxa máxima de que 
o hardware é capaz. Se os blocos foram numerados, como 
na Figura 3-4(a), mas a controladora apenas consegue ler 
blocos alternados, um sistema operacional que alocasse um 
arquivo de oito blocos em blocos de disco consecutivos exi¬ 
giria oito rotações de disco para ler os blocos de 0 a 7 em 
ordem. (Naturalmente, se o sistema operacional soubesse 
do problema e alocasse seus blocos de maneira diferente, 
ele poderia resolver o problema no nível de software, mas é 
melhor ter a controladora preocupando-se com a interca¬ 
lação.) 

Nem todos os computadores utilizam DMA. 0 argumen¬ 
to contra é que a CPU principal é freqüentemente milito 
mais rápida que a controladora de DMA e pode fazer o tra¬ 
balho muito mais rápido (quando o fator limitante não é a 
velocidade do dispositivo de E/S). Se não houver outro tra¬ 
balho para ela fazer, ter a (rápida) CPU esperando a (len¬ 
ta) controladora de DMA é algo sem sentido. Além disso, 
livrar-se da controladora de DMA e ter a CPU fazendo todo 
o trabalho em software economiza algum dinheiro. 



SISTEMAS OPERACIONAIS 117 



Figura 3-3 Uma transferência de DMA é feita inteiramente pela controladora. 


3.2 PRINCÍPIOS BÁSICOS DO 
SOFTWARE DE E/S 

Permita-nos desviar do hardware por um momento e 
ver como o software de E/S é estruturado. As metas gerais 
do software de E/S são fáceis de declarar. A idéia básica é 
organizar o software como uma série de camadas, com as 
mais baixas preocupadas em esconder as peculiaridades 
do hardware das mais altas e estas últimas preocupadas 
em apresentar uma interface amigável, limpa e simples 
aos usuários. Nas seções a seguir veremos essas metas e 
como elas são alcançadas. 

3-2.1 Metas do Software de E/S 

Um conceito-chave no projeto de software de E/S é co¬ 
nhecido como independência de dispositivo. Isso signi¬ 
fica que deve ser possível escrever programas que podem 
ler arquivos em um disquete, em um disco rígido ou em 
um CD-ROM, sem que seja necessário modificar os pro¬ 
gramas para cada tipo de dispositivo diferente. Qualquer 
um deve ser capaz de digitar um comando como 

sort <input> output 

e fazê-lo funcionar com a entrada proveniente de um dis¬ 
quete de um disco rígido ou o teclado e a saída indo para o 


disquete, para o disco rígido ou até para a tela. Cabe ao 
sistema operacional cuidar dos problemas causados pelo 
fato de que esses dispositivos realmente são diferentes e re¬ 
querem drivers de dispositivo muito diferentes para real¬ 
mente gravar os dados no dispositivo de saída. 

Intimamente relacionada com a independência de dis¬ 
positivo está a meta de atribuição uniforme de nomes. 
0 nome de um arquivo ou de um dispositivo deve ser sim¬ 
plesmente uma string ou um número inteiro e não depen¬ 
der do dispositivo de nenhuma maneira. No UNIX, todos os 
discos podem estar integrados juntos na hierarquia do sis¬ 
tema de arquivos de maneiras arbitrárias para que o usuá¬ 
rio não precise saber qual nome corresponde a qual dispo¬ 
sitivo. Por exemplo, um disquete pode ser montado no di¬ 
retório /usr/ast/backup de tal modo que a ação de copiar 
um arquivo p-àva./usr/ast/backup/monday copie o arqui¬ 
vo para o disquete. Assim, todos os arquivos e os dispositi¬ 
vos são endereçados da mesma maneira: por um nome de 
caminho. 

Outra questão importante para o software de E/S é o 
tratamento de erros. Em geral, os erros devem ser tratados 
o mais perto possível do hardware. Se a controladora des¬ 
cobrir um erro de leitura, ela deverá tentar corrigir o erro 
se puder. Se não puder, então o driver de dispositivo deverá 
tratá-lo, talvez tentando simplesmente ler o bloco nova¬ 
mente. Muitos erros são transitórios, como aqueles de lei- 





(a) (b) (c) 


Figura 3-4 (a) Nenhuma intercalação, (b) Intercalação única, (c) Intercalação dupla. 
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tura causados por partículas de pó no cabeçote de leitura e 
desaparecem se a operação é repetida. Somente quando as 
camadas mais baixas não são capazes de lidar com o pro¬ 
blema é que as camadas superiores devem ser informadas. 
Em muitos casos, a recuperação de erros pode ser feita trans¬ 
parentemente em um nível baixo, sem que os níveis supe¬ 
riores nem mesmo saibam sobre o erro. 

Outra questão-chave são as transferências síncronas 
(com bloqueio) versus assíncronas (baseadas em interrup¬ 
ções) . A maior parte da E/S é assíncrona — a CPU inicia a 
transferência e segue adiante para fazer outra coisa ate' a 
interrupção chegar. Os programas de usuário são muito 
mais fáceis de escrever se as operações de E/S provocarem 
bloqueios — depois de um comando READ o programa é 
automaticamente suspenso até que os dados estejam dis¬ 
poníveis no buffer. Cabe ao sistema operacional fazer com 
que as operações que são de fato baseadas em interrupções 
parecerem-se com bloqueios para os programas do usuá¬ 
rio. 

O conceito final com que lidaremos aqui é dispositivos 
compartilháveis versus dispositivos dedicados. Alguns dis¬ 
positivos de E/S, como discos, podem ser utilizados por 
muitos usuários ao mesmo tempo. Nenhum problema é 
causado por múltiplos usuários tendo arquivos abertos no 
mesmo disco ao mesmo tempo. Outros dispositivos, como 
unidades de fita, precisam ser dedicados a um único usuá¬ 
rio até que esse usuário tenha terminado. Então, outro usu¬ 
ário pode ter a unidade de fita. Ter dois ou mais usuários 
gravando blocos misturados aleatoriamente na mesma fita 
definitivamente não funcionará. A introdução de dispositi¬ 
vos dedicados (não-compartilhados) também introduz uma 
variedade de problemas. Novamente, o sistema operacio¬ 
nal deve ser capaz de tratar dispositivos tanto compartilha¬ 
dos como dedicados de uma maneira que evite problemas. 

Essas metas podem ser alcançadas de uma maneira efi¬ 
ciente e abrangente estruturando o software de E/S em qua¬ 
tro camadas: 

1. Manipuladores de interrupções (fundo). 

2. Drivers de dispositivo. 

3. Software de sistema operacional independente de 
dispositivo. 

4. Software de nível de usuário (topo). 

Essas quatro camadas são (não acidentalmente) as 
mesmas quatro camadas que vimos na Figura 2-26. Nas 
seções a seguir veremos uma por vez, começando pelo fun¬ 
do. A ênfase neste capítulo está nos drivers de dispositivo 
(camada 2), mas resumiremos o restante do software de E/ 
S para mostrar como as várias partes do sistema de E/S 
ajustam-se entre si. 

3.2.2 Manipuladores de Interrupções 

Interrupções são uma realidade desagradável. Elas de¬ 
vem ser escondidas longe, no fundo das entranhas do siste¬ 
ma operacional, de modo que o mínimo possível do siste¬ 
ma saiba sobre elas. A melhor maneira de ocultá-las é ter 


cada processo que inicia uma operação de E/S bloqueado 
até que a E/S tenha-se completado e a interrupção tenha 
ocorrido. O processo pode bloquear-se fazendo um DOWX 
em um semáforo, um wait em uma variável de condição 
ou um RECHiVE em uma mensagem, por exemplo. 

Quando as interrupções acontecem, o procedimento de 
interrupção faz o que tem de fazer para desbloquear o pro¬ 
cesso que iniciou a E/S. Em alguns sistemas, ele fará um 
UP em um semáforo. Em outros, ele fará um SIGXAI. em 
uma variável de condição em um monitor. Em outros, ain¬ 
da, ele enviará uma mensagem para o processo bloquea¬ 
do. Em todos casos, o efeito geral da interrupção será que 
um processo que anteriormente estava bloqueado agora será 
capaz de executar. 

3.2.3 Drivers de Dispositivo 

Todo código dependente de dispositivo deve estar nos 
drivers de dispositivos. Cada driver de dispositivo trata de 
um tipo de dispositivo ou, no máximo, de uma classe de 
dispositivos intimamente relacionados. Por exemplo, pro¬ 
vavelmente seria uma boa idéia ter um único driver de 
terminal, mesmo que o sistema suportasse diversos tipos 
de terminal, todos ligeiramente diferentes. Por outro lado, 
um terminal burro para a impressão de listagens e um ter¬ 
minal gráfico inteligente com um mouse são tão diferen¬ 
ciados que drivers diferentes deverão ser utilizados. 

Anteriormente neste capítulo vimos o que as controla¬ 
doras de dispositivo fazem. Vimos que cada controladora 
tem um ou mais registradores de dispositivo utilizados para 
receber comandos. Os drivers de dispositivo enviam esses 
comandos e verificam se eles foram executados adequada¬ 
mente. Assim, o driver de disco é a única parte do sistema 
operacional que sabe quantos registradores tal controlado¬ 
ra de disco tem e para o que eles são utilizados. Sozinho, 
ele sabe tudo sobre setores, trilhas, cilindros, cabeçotes, 
movimento do braço, fatores de intercalação, unidades de 
motor, tempos de acomodação do cabeçote, e todos os ou¬ 
tros fatores mecânicos envolvidos no trabalho de fazer o 
disco funcionar adequadamente. 

Em termos gerais, o trabalho de um driver de dispositi¬ 
vo é aceitar solicitações abstratas do software independen¬ 
te de dispositivo acima dele e cuidar para que a solicitação 
seja executada. Uma solicitação típica é ler o bloco n. Se o 
driver estiver desocupado no momento em que uma soli¬ 
citação chega, ele começa a executar a solicitação imedia¬ 
tamente. Se, entretanto, ele já estiver ocupado com uma 
solicitação, normalmente ele colocará a nova solicitação 
em uma fila de solicitações pendentes a serem tratadas logo 
que possível. 

O primeiro passo para realmente executar uma solici¬ 
tação de E/S. digamos, para um disco, é traduzi-la de um 
termo abstrato para um termo concreto. Para um driver 
de disco, isso significa descobrir onde no disco o bloco re¬ 
querido realmente está, verificar se o motor da unidade está 
ligado, determinar se o braço está posicionado no cilindro 
adequado e assim por diante. Em resumo, ele deve decidir 
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que operações da controladora são requeridas e em que 
seqüência. 

Uma vez determinados quais comandos serão enviados 
para a controladora, ele começa a emitir esses comandos 
gravando nos registradores de dispositivo da controladora. 
Algumas controladoras podem tratar somente um coman¬ 
do por vez. Outras aceitam uma lista encadeada de coman¬ 
dos, que, então, executam sozinhas, sem ajuda do sistema 
operacional. 

Depois que o comando ou os comandos foram dados, 
uma de duas situações será aplicada. Em muitos casos, o 
driver de dispositivo deve esperar até que a controladora 
faça algum trabalho para ele; então, ele bloqueia a si pró¬ 
prio até que as interrupções entrem para desbloqueá-lo. 
Em outros casos, entretanto, a operação acaba sem demo¬ 
ra, assim o driver não precisa bloquear. Como um exem¬ 
plo desta última situação, a ação de rolar a tela em alguns 
terminais requer simplesmente gravar alguns bytes nos re¬ 
gistradores da controladora. Nenhum movimento mecâ¬ 
nico é necessário; então, a operação inteira pode ser com¬ 
pletada em alguns microssegundos. 

No primeiro caso, o driver suspenso será acordado pela 
interrupção. No último caso, ele nunca irá dormir. De qual¬ 
quer maneira, depois que a operação foi completada, ele 
deve fazer uma verificação de erros. Se tudo estiver certo, o 
driver pode ter dados para passar para o software indepen¬ 
dente de dispositivo (p. ex., um bloco recém-lido). Por fim, 
ele retorna algumas informações de status para informe 
de erro para quem o chamou. Se quaisquer outras solicita¬ 
ções estiverem enfileiradas, uma delas agora pode ser sele¬ 
cionada e iniciada. Se nada estiver enfileirado, o driver é 
bloqueado e fica aguardando a próxima solicitação. 

3.2.4 Software de E/S Independente de 
Dispositivo 

Embora parte do software de E/S seja específico de dis¬ 
positivo, uma grande parte dele é independente de disposi¬ 
tivo. A divisão exata entre os drivers e o software indepen¬ 
dente de dispositivo depende do sistema, porque algumas 
funções que poderiam ser feitas de uma maneira indepen¬ 


dente de dispositivo podem, na realidade, ser feitas nos dri¬ 
vers, por eficiência ou por outras razões. As funções mos¬ 
tradas na Figura 3-5 geralmente são feitas no software in¬ 
dependente de dispositivo. No MIMX, a maioria do software 
independente de dispositivo é parte do sistema de arquivos, 
na camada 3 (Figura 2-26). Embora estudaremos o siste¬ 
ma de arquivos no Capítulo 5, veremos aqui rapidamente 
o software independente de dispositivo para oferecer uma 
perspectiva da E/S e mostrar melhor onde os drivers en¬ 
quadram-se. 

A função básica do software independente de dispositi¬ 
vo é executar as funções de E/S que são comuns para todos 
dispositivos e oferecer uma interface uniforme para o sof¬ 
tware de nível de usuário. 

Uma questão importante em um sistema operacional é 
a maneira como são nomeados objetos como arquivos e 
dispositivos de E/S. O software independente de dispositivo 
cuida de mapear nomes simbólicos de dispositivo para o 
driver adequado. No UNIX, um nome de dispositivo, como/ 
dev/ttyOO , especifica unicamente o nó-i para um arquivo 
especial, e esse nó-i contém o número principal do dis¬ 
positivo, que é utilizado para localizar o driver apropria¬ 
do. 0 nó-i também contém o número secundário do dis¬ 
positivo, que é passado como um parâmetro para o driver 
para especificar a unidade a ler ou a gravar. 

Intimamente relacionado com a nomeação está a pro¬ 
teção. Como o sistema impede que os usuários acessem dis¬ 
positivos aos quais eles não têm direitos de acesso? Na mai¬ 
oria dos sistemas de computador pessoal, não há nenhu¬ 
ma proteção. Qualquer processo pode fazer qualquer coisa 
que quiser. Na maioria dos sistemas de mainframe , o acesso 
a dispositivos de E/S por processos de usuário é completa¬ 
mente proibido. No UNIX, um esquema mais flexível é uti¬ 
lizado. Os arquivos especiais correspondentes aos dispositi¬ 
vos de E/S são protegidos pelos bits rwx normais. 0 admi¬ 
nistrador de sistema pode, então, configurar as permissões 
adequadas para cada dispositivo. 

Discos diferentes podem ter tamanhos de setor diferen¬ 
tes. Cabe ao software independente de dispositivo esconder 
esse fato e oferecer um tamanho uniforme de bloco para as 
camadas mais altas, por exemplo, tratando vários setores 


Interfaceamento uniforme para drivers de dispositivo 
Nomeação de dispositivo 
Proteção de dispositivo 

Fornecimento de um tamanho de bloco independente de dispositivo 
Bufferização 

Alocação de armazenamento em dispositivos de bloco 
Atribuição e liberação de dispositivos dedicados 
Informe de erros 


Figura 3-5 As funções do software de E/S independente de dispositivo. 
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como um único bloco lógico. Dessa maneira, as camadas 
mais altas lidam somente com dispositivos abstratos, que 
utilizam o mesmo tamanho de bloco lógico, independente 
do tamanho físico do setor. De maneira semelhante, alguns 
dispositivos de caractere entregam seus dados à freqüência 
de um byte por vez (p. ex., modems), enquanto outros en¬ 
tregam seus dados em unidades maiores (p. ex., interfaces 
de rede). Essas diferenças também devem ser ocultadas. 

A bufferização também é uma questão, tanto para dis¬ 
positivos de bloco como para os de caractere. Para dispositi¬ 
vos de bloco, o hardware geralmente insiste em ler e em 
gravar blocos inteiros de uma vez, mas processos de usuá¬ 
rio são livres para ler e para gravar em unidades arbitrári¬ 
as. Se um processo de usuário gravar metade de um bloco, 
o sistema operacional nonnalmente manterá os dados in- 
temamente até que o resto dos dados sejam gravados, mo¬ 
mento em que o bloco pode sair para o disco. Para disposi¬ 
tivos de caractere, os usuários podem gravar dados no siste¬ 
ma mais rapidamente do que ele pode dar saída, precisan¬ 
do, então, de bufferização. A entrada de teclado que chega 
antes de ser necessária também requer bufferização. 

Quando um arquivo é criado e é preenchido com da¬ 
dos, novos blocos de disco precisam ser alocados para o 
arquivo. Para executar essa alocação, o sistema operacio¬ 
nal precisa de uma lista ou um mapa de bits dos blocos 
livres por disco, mas o algoritmo para localizar um bloco 
livre é independente de dispositivo e pode ser feito acima 
do nível do driver. 

Alguns dispositivos, como gravadores de CD-ROM, po¬ 
dem ser utilizados somente por um único processo em um 
momento qualquer. Cabe ao sistema operacional exami¬ 
nar as solicitações para utilização de dispositivo e aceitá- 
las ou rejeitá-las, dependendo se o dispositivo requerido 
estiver disponível ou não. Uma maneira simples de tratar 
essas solicitações é requerer que os processos executem OPEN 
diretamente nos arquivos especiais para dispositivos. Se o 
dispositivo estiver indisponível, o OPEN falhará. 0 fecha¬ 
mento de um dispositivo dedicado iria liberá-lo. 

0 tratamento de erros, de modo geral, é feito pelos dri¬ 
vers. A maioria dos erros é altamente dependente do dispo¬ 
sitivo; então, somente o driver sabe o que fazer (p. ex., ten¬ 
tar novamente, ignorar, pane). Um erro típico é causado 
por um bloco de disco danificado que não pode ser mais 
lido. Depois que o driver tentou ler o bloco um certo nú¬ 
mero de vezes, ele desiste e informa ao software indepen¬ 
dente de dispositivo. A maneira como o erro é tratado da¬ 
qui é independente de dispositivo. Se o erro ocorreu duran¬ 
te a leitura de um arquivo de usuário, pode ser suficiente 
informar o erro ao processo que registrou a leitura. Entre¬ 
tanto, se ele ocorreu durante a leitura de uma estrutura de 
dados crítica do sistema, como o bloco que contém o mapa 
de bits mostrando quais blocos estão livres, o sistema ope¬ 
racional não pode ter outra escolha senão imprimir uma 
mensagem de erro e terminar. 


3.2.5 Software de E/S no Espaço do 
Usuário 

Embora a maioria do software de E/S esteja dentro do 
sistema operacional, uma pequena parte consiste em bi¬ 
bliotecas vinculadas em programas de usuário, e até mes¬ 
mo programas inteiros que executam fora do kernel. As 
chamadas de sistema, incluindo as chamadas de sistema 
de E/S, normalmente são feitas por procedimentos de bi¬ 
blioteca. Quando um programa de C contém a chamada 

count = write(fd, buffer, nbytes); 

o procedimento de biblioteca write será vinculado com o 
programa e estará contido no programa binário presente 
na memória em tempo de execução. A coleção de todos 
esses procedimentos de biblioteca é claramente parte do 
sistema de E/S. 

Embora esses procedimentos façam pouco mais que 
colocar seus parâmetros no lugar apropriado para a cha¬ 
mada de sistema, há outros procedimentos de E/S que de 
fato fazem trabalho real. Em particular, a formatação de 
entrada e de saída é feita pelos procedimentos de bibliote¬ 
ca. Um exemplo de C é printf, que pega uma string de for¬ 
mato e possivelmente algumas variáveis como entrada, 
constrói urna string de ASCII e, então, chama WRITE para 
dar saída à string. Um exemplo de um procedimento se¬ 
melhante para entrada é scanf que lê a entrada e armaze¬ 
na-a em variáveis descritas em uma string de formato que 
usa a mesma sintaxe de printf. A biblioteca-padrão de E/S 
contém diversos procedimentos que envolvem E/S e todas 
executam como parte de programas de usuário. 

Nem todo software de E/S no nível de usuário consiste 
em procedimentos de biblioteca. Outra categoria importante 
é o sistema de spool. Fazer spool é uma maneira de lidar 
com dispositivos dedicados de E/S em um sistema de mul- 
tiprogramação. Considere um dispositivo típico para o qual 
se ízispool: uma impressora. Embora pudesse ser uma téc¬ 
nica fácil deixar qualquer processo de usuário abrir o ar¬ 
quivo especial de caractere para a impressora, suponha que 
um processo abrisse-o e, então, não fizesse nada durante 
horas. Nenhum outro processo poderia imprimir qualquer 
coisa. 

Em vez disso, o que é feito é criar um processo especial, 
chamado daetnon, e um diretório especial, chamado di¬ 
retório de spool. Para imprimir um arquivo, um proces¬ 
so primeiro gera o arquivo inteiro a ser impresso e coloca- 
o no diretório de spool. Cabe ao daemon, o único processo 
a ter permissão para utilizar o arquivo especial da impres¬ 
sora, imprimir os arquivos no diretório. Protegendo o ar¬ 
quivo especial contra o uso direto dos usuários, o proble¬ 
ma de ter alguém mantendo-o aberto desnecessariamente 
é eliminado. 

A técnica de spool não é utilizada apenas para impres¬ 
soras. Ela também é utilizada em outras situações, como, 
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por exemplo, transferência de arquivos por uma rede, quan¬ 
do frequentemente é utilizado um daemon de rede. Para 
enviar um arquivo para algum lugar, um usuário coloca-o 
em um diretório d espool da rede. Mais tarde, o daemon de 
rede pega-o e transmite-o. Um exemplo particular de trans¬ 
missão de arquivo utilizando ospool é o sistema de correio 
eletrônico da Internet. Essa rede consiste em milhões de 
máquinas ao redor do mundo utilizando muita redes de 
computador que se comunicam entre si. Para enviar uma 
mensagem para alguém, você chama um programa como 
send, que recebe a carta a ser enviada e, então, deposita-a 
em um diretório de spool para ser transmitida posterior¬ 
mente. 0 sistema inteiro de correio executa fora do sistema 
operacional. 

A Figura 3-6 resume o sistema de E/S, mostrando todas 
as camadas e as principais funções de cada uma. Come¬ 
çando do fundo, as camadas são o hardware, os manipula¬ 
dores de interrupções, os drivers de dispositivo, o software 
independente de dispositivo e, por fim, os processos de usu¬ 
ário. 

As setas na Figura 3-6 mostram o fluxo de controle. 
Quando um programa de usuário tenta ler um bloco de 
um arquivo, por exemplo, o sistema operacional é invoca¬ 
do para executar a chamada. O software independente de 
dispositivo olha no cache de blocos, por exemplo. Se o blo¬ 
co necessário não estiver aí, ele chama o driver de disposi¬ 
tivo para enviar a solicitação ao hardware. 0 processo, en¬ 
tão, é bloqueado até que a operação de disco seja concluí¬ 
da. 

Quando o disco termina, o hardware, gera uma inter¬ 
rupção. O manipulador de interrupções é executado para 
descobrir o que aconteceu, isto é, qual dispositivo quer aten¬ 
ção imediatamente. Então, ele extrai o status do dispositi¬ 
vo e acorda o processo adormecido para terminar a solici¬ 
tação de E/S e deixar o processo de usuário continuar. 


3-3 IMPASSES 

Os sistemas de computador estão repletos de recursos 
que podem ser utilizados apenas por um processo por vez. 
Exemplos comuns incluem plotadoras, leitores de CD-ROM, 
gravadores de CD-ROM, sistemas de backup em unidade 
de fita DAT 8mm e entradas na tabela de processos do siste¬ 
ma. Ter dois processos simultaneamente gravando na im¬ 
pressora resulta em uma confusão. Ter dois processos que 
utilizam a mesma entrada na tabela de processos prova¬ 
velmente levará a uma queda do sistema. Portanto, todos 
os sistemas operacionais têm a capacidade de (tempora¬ 
riamente) conceder acesso exclusivo a certos recursos para 
um processo. 

Para muitos aplicativos, um processo requer acesso ex¬ 
clusivo não a um, mas a vários recursos. Considere, por 
exemplo, uma empresa de marketing especializada em fa¬ 
zer grandes e detalhados mapas demográficos do país em 
uma plotadora de lm de largura. As informações demo¬ 
gráficas vêm de CD-ROMS contendo o censo e outros da¬ 
dos. Suponha que o processo ri solicita a unidade de CD- 
ROM e obtém-na. Um momento mais tarde, o processo B 
solicita a plotadora e obtém-na também. Agora o processo 
ri solicita a plotadora e bloqueia, esperando por ela. Por 
fim, o processo B solicita a unidade de CD-ROM e também 
bloqueia. Neste ponto, os dois processos estão bloqueados e 
permanecerão assim eternamente. Essa situação é chama¬ 
da impasse ( deadlock ). Os impasses não são uma boa 
coisa para ter em seu sistema. 

Os impasses podem ocorrer em muitas situações além 
dessa de solicitar dispositivos dedicados de E/S. Em um sis¬ 
tema de banco de dados, por exemplo, um programa pode 
precisar travar vários registros que ele está utilizando, para 
evitar condições de corrida. Se o processori trava o registro 
RI e o processo B trava o registro R2, e cada processo, en- 
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Figura 3-6 As camadas do sistema de E/S e as principais funções de cada uma. 
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tão, tenta travar o registro do outro, também temos um 
impasse. Os impasses, portanto, podem ocorrer em recur¬ 
sos de hardware ou em recursos de software. 

Nesta seção, examinaremos impasses mais de perto para 
ver como eles surgem e como podem ser prevenidos ou evi¬ 
tados. Como exemplos, discutiremos a aquisição de dispo¬ 
sitivos físicos como unidades de fita, unidades de CD-ROM 
e plotadoras, porque tais dispositivos são fáceis de visuali¬ 
zar, mas os princípios e os algoritmos aplicam-se igual¬ 
mente bem a outros tipos de impasses. 

3-3.1 Recursos 

Os impasses podem ocorrer quando se concede aos pro¬ 
cessos acesso exclusivo a dispositivos, a arquivos, etc. Para 
tornar a discussão sobre impasses 0 mais geral possível, 
vamos referir-nos aos objetos concedidos como recursos. 
Um recurso pode ser um dispositivo de hardware (p. ex., 
uma unidade de fita) ou um conjunto de informações (p. 
ex., um registro bloqueado em um banco de dados). Um 
computador normalmente terá muitos recursos diferentes 
que podem ser adquiridos. Para alguns recursos, vários 
exemplares idênticos podem estar disponíveis, como três 
unidades de fita. Quando várias cópias de um recurso es¬ 
tão disponíveis, qualquer uma delas pode ser utilizada para 
satisfazer qualquer solicitação ao recurso. Em resumo, um 
recurso é qualquer coisa que pode ser utilizada somente 
por um único processo em qualquer instante. 

Os recursos dividem-se em dois tipos: preemptível e não- 
preemptível. Um recurso preemptível é aquele que pode 
ser tirado do processo que é proprietário dele sem nenhum 
problema. A memória é um exemplo de um recurso pre¬ 
emptível. Considere, por exemplo, um sistema com 512K 
de memória de usuário, uma impressora e dois processos 
de 512K, cada um querendo imprimir algo. O processo A 
solicita e obtém a impressora, então, começa a calcular os 
valores a imprimir. Antes de finalizar os cálculos, ele exce¬ 
de seu quantum de tempo e é comutado para 0 disco. 

0 processo B agora executa e tenta, sem sucesso, obter a 
impressora. Potencialmente, agora temos uma situação de 
impasse, porque d tem a impressora e B tem a memória e 
nem um nem outro pode prosseguir sem 0 recurso segura¬ 
do pelo outro. Felizmente, é possível preemptar (tirar) a 
memória de B comutando-a para 0 disco e comutando A 
para a memória. Agora d pode executar, fazer sua impres¬ 
são e, então, liberar a impressora. Nenhum impasse ocorre. 

Um recurso não-preemptível, em oposição, é aquele 
que não pode ser tirado de seu proprietário atual sem cau¬ 
sar falha na computação. Se um processo começou a im¬ 
primir uma saída, a ação de tomar a impressora dele e dá- 
la a outro processo resultará em problemas na saída. As 
impressoras não são preemptíveis. 

Em geral, impasses envolvem recursos não-preemptí- 
veis. Impasses potenciais que envolvem recursos preemptí¬ 
veis normalmente podem ser resolvidos mediante a realo- 
cação de recursos de um processo para outro. Assim, nosso 
tratamento irá concentrar-se em recursos não-preemptíveis. 


A seqüência de eventos requerida para utilizar um re¬ 
curso é: 

1. Solicitar 0 recurso. 

2. Utilizar 0 recurso. 

3. Liberar 0 recurso. 

Se 0 recurso não estiver disponível quando for solicitado, 0 
processo solicitante é forçado a esperar. Em alguns siste¬ 
mas operacionais, 0 processo é automaticamente bloquea¬ 
do quando uma solicitação de recurso falha e é acordado 
quando 0 recurso torna-se disponível. Em outros sistemas, 
a solicitação falha com um código de erro e cabe ao pro¬ 
cesso de chamada esperar alguns instantes e tentar nova¬ 
mente. 

3.3.2 Princípios Básicos de Impasses 

O impasse pode ser definido formalmente como segue: 

Um conjunto de processos está em um impasse se cada 

processo no conjunto está esperajido um evento que 

somente outro processo no conjunto pode causar. 

Como todos os processos estão esperando, nenhum deles 
jamais causará qualquer dos eventos que poderiam acor¬ 
dar qualquer dos outros membros do conjunto e todos os 
processos continuam a esperar eternamente. 

Na maioria dos casos, 0 evento que cada processo está 
esperando é a liberação de algum recurso atualmente pos¬ 
suído por outro membro do conjunto. Em outras palavras, 
cada membro do conjunto de processos em impasse está 
esperando um recurso que é possuído por um processo em 
estado de impasse. Nenhum dos processos pode executar, 
nenhum deles pode liberar qualquer recurso e nenhum 
deles pode ser acordado. 0 número de processos e 0 núme¬ 
ro e 0 tipo de recursos possuídos e requeridos não têm im¬ 
portância. 

Condições para um Impasse 

Coffman e colaboradores (1971) demonstraram que 
quatro condições devem ser sustentadas para haver um 
impasse: 

1. Condição de exclusão mútua. Todo recurso está 
atribuído a exatamente um processo ou está dis¬ 
ponível. 

2. Condição de segura e espera. Os processos que es¬ 
tão segurando recursos concedidos anteriormente 
podem solicitar novos recursos. 

3. Condição de nenhuma preempção. Os recursos 
previamente concedidos não podem ser tirados de 
um processo. Eles devem ser explicitamente libe¬ 
rados pelo processo que os está segurando. 

4. Condição de espera circular. Deve haver uma ca¬ 
deia circular de dois ou mais processos, cada um 
dos quais está esperando um recurso segurado pelo 
próximo membro da cadeia. 
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Todas essas quatro condições devem estar presentes para 
um impasse ocorrer. Se uma ou mais dessas condições esti¬ 
ver ausente, nenhum impasse é possível. 

Modelamento de Impasse 

Holt (1972) demonstrou como essas quatro condições 
podem ser modeladas utilizando grafos dirigidos. Os gra- 
fos têm dois tipos de nós: processos, mostrados como círcu¬ 
los, e recursos, mostrados como quadrados. Um arco de 
um nó de recurso (quadrado) para um nó de processo (cír¬ 
culo) significa que 0 recurso previamente foi solicitado por, 
concedido para, e atualmente está sendo segurado por esse 
processo. Na Figura 3-7(a), o recurso R está atualmente 
atribuído ao processo d. 

Um arco de um processo para um recurso significa que 
0 processo atualmente está bloqueado esperando esse re¬ 
curso. Na Figura 3-7(b), o processo B está esperando o re¬ 
curso S. Na Figura 3-7 (c) vemos um impasse: o processo C 
está esperando o recurso 7', que atualmente está sendo se¬ 
gurado pelo processo D. O processo D não irá liberar o re¬ 
curso T porque está esperando o recurso U, que está sendo 
segurado por C. Os dois processos esperarão eternamente. 
Um ciclo no grafo significa que há um impasse envolven¬ 
do os processos e os recursos no ciclo. Nesse exemplo, o 
ciclo é C-T-D-U-C. 

Agora vamos olhar um exemplo de como grafos de re¬ 
curso podem ser utilizados. Imagine que temos três pro¬ 
cessos,/!, B eCe três recursos, R, S e T. As solicitações e as 
liberações dos três processos são dadas na Figura 3-8(a)- 
(c) 0 sistema operacional é livre para executar qualquer 
processo desbloqueado a qualquer instante, portanto, ele 
poderia decidir executar A ate' que .4 termine todo seu tra¬ 
balho, depois executar B até a conclusão e por fim execu¬ 
tar C. 

Essa ordem não conduz a nenhum impasse (porque 
não há nenhuma competição por recursos), mas também 
não tem qualquer paralelismo. Além de solicitar e de libe¬ 
rar recursos, os processos computam e fazem E/S. Quando 
os processos são executados seqüencialmente não há ne¬ 
nhuma possibilidade de que, enquanto um processo está 
esperando E/S, outro possa utilizar a CPU. No entanto, exe¬ 


cutar os processos precisamente na seqüência pode não ser 
ótimo. Por outro lado, se nenhum dos processos fizer algu¬ 
ma E/S, o job mais curto primeiro é melhor que round 
robin, então, sob algumas circunstâncias executar todos 
os processos seqüencialmente pode ser o melhor caminho. 

Agora vamos supor que os processos fazem tanto E/S 
como computações, de modo que o round robin torne-se 
um algoritmo de agendamento aceitável. As solicitações de 
recurso podem ocorrer na ordem da Figura 3-8(d). Se es¬ 
sas seis solicitações forem executadas nessa ordem, os seis 
grafos de recurso resultantes são mostrados na Figura 3- 
8(e)-(j). Depois que a solicitação 4 foi feita, A bloqueia 
esperando A. como mostrado na Figura 3-8 (h). Nos próxi¬ 
mos dois passos B e C também bloqueiam, conduzindo a 
um ciclo e ao impasse da Figura 3-8(j) 

Entretanto, como já mencionamos, não se exige que o 
sistema operacional execute os processos em qualquer or¬ 
dem especial. Em particular, se a concessão de uma solici¬ 
tação particular pode levar a um impasse, o sistema opera¬ 
cional pode simplesmente suspender o processo sem con¬ 
ceder a solicitação (i. e., simplesmente não agenda o pro¬ 
cesso) até que ele esteja seguro. Na Figura 3-8, se o sistema 
operacional soubesse sobre o impasse prestes a acontecer, 
ele poderia suspender B em vez de conceder-lhe 3’. Execu¬ 
tando somente/l e C, obteríamos as solicitações e as libera¬ 
ções da Figura 3-8(k) em vez da Figura 3-8(d). Essa se¬ 
qüência leva aos grafos de recurso da Figura 3-8(l)-(q), 
que não leva a impasse. 

Após o passo (q), o processo B pode receber S porque A 
terminou e C tem tudo que precisa. Mesmo que B acabasse 
bloqueando ao solicitar 7) nenhum impasse poderia ocor¬ 
rer. B somente irá espera até que C termine. 

Mais adiante neste capítulo, estudaremos um algorit¬ 
mo detalhado para fazer decisões de alocação que não le¬ 
vam a um impasse. O ponto a entender agora é que grafos 
de recurso são uma ferramenta que permite ver se uma 
dada seqüência de solicitação/liberação leva a impasse. Nós 
simplesmente executamos as solicitações e as liberações 
passo a passo e depois de cada passo verificamos o grafo 
para ver se ele contém qualquer ciclo. Se contiver, temos 
um impasse; caso contrário, não há impasse. Embora nos¬ 
so tratamento de grafos de recurso foi para o caso de um 
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Figura 3-7 Grafos de alocação de recursos, (a) Segurando um recurso, (b) Solicitando um recurso, (c) Impasse. 
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único recurso de cada tipo, grafos de recursos também po¬ 
dem ser generalizados para tratar múltiplos recursos do 
mesmo tipo (Holt, 1972). 

Em geral, quatro estratégias são utilizadas para lidar 
com impasses. 

1. Simplesmente ignorar o problema. 

2. Detecção e recuperação. 

3. Impedimento dinâmico por cuidadosa alocação de 
recursos. 

4. Prevenção, pela negação estrutural de uma das 
quatro condições necessárias. 

Examinaremos cada um desses métodos nas próximas 
quatro seções. 

3.3.3 O Algoritmo do Avestruz 

A abordagem mais simples é o algoritmo do avestruz: 
enfie sua cabeça na areia e finja que não há nenhum pro¬ 
blema. Pessoas diferentes reagem a essa estratégia de ma¬ 
neiras diferentes. Os matemáticos consideram-na totalmen¬ 
te inaceitável e dizem que impasses devem ser evitados a 
todo custo. Os engenheiros perguntam sobre a freqüência 
esperada do problema, sobre a freqüência das quedas de 
sistema por outras razões e sobre a gravidade do impasse. 
Se os impasses ocorressem à média de uma vez a cada 50 
anos, mas quedas do sistema devido a falhas de hardware, 
erros de compilador e bugs do sistema operacional ocor¬ 
rem uma vez por mês, a maioria dos engenheiros não esta¬ 
ria disposta a pagar um preço tão alto no desempenho ou 
na conveniência para eliminar impasses. 

Para tornar esse contraste mais específico, o UNIX (e o 
minix) potencialmente passa por impasses que não são nem 
mesmo detectados, para não dizer automaticamente inter¬ 
rompidos. O número total de processos no sistema é deter¬ 
minado pelo número de entradas na tabela de processos. 
Assim as entradas da tabela de processos são recursos fini¬ 
tos. Se um fork falha porque a tabela está cheia, uma abor¬ 
dagem razoável para o programa que faz o FORK é esperar 
um tempo aleatório e tentar novamente. 

Agora suponha que um sistema UNIX tem 100 entradas 
de processos. Dez programas estão executando, cada um 
dos quais necessita criar 12 (sub)processos. Depois que cada 
processo criou 9 processos, os 10 processos originais e os 90 
novos processos esgotaram a tabela. Cada um dos 10 pro¬ 
cessos originais agora fica em um laço interminável de cri¬ 
ação e de falha—um impasse. A probabilidade desse evento 
é ínfima, mas ele pode acontecer. Deveríamos abandonar 
processos e a chamada FORK para eliminar o problema? 

O número máximo de arquivos abertos é de maneira 
semelhante restringido pelo tamanho da tabela de nós-i; 
então, um problema semelhante ocorre quando ela é com¬ 
pletamente preenchida. Espaço de troca \swap) em disco é 
outro recurso limitado. De fato, quase todas as tabelas no 
sistema operacional representam um recurso finito. Deve¬ 


ríamos abolir tudo isso porque talvez aconteça de uma co¬ 
leção de n processos reivindicar 1 /n do total para cada um 
e, então, todos tentarem reivindicar algo mais? 

A abordagem do UNIX é simplesmente ignorar o proble¬ 
ma na suposição de que a maioria dos usuários preferiria 
um impasse ocasional a uma regra que restringisse todos 
os usuários a um processo, a um arquivo aberto e “tudo" 
um. Se os impasses pudessem ser eliminados livremente, 
não haveria muita discussão. O problema é que o preço é 
alto, principalmente em termos de impor restrições incon¬ 
venientes em processos, como veremos brevemente. Assim 
nos defrontamos com uma negociação desagradável entre 
conveniência e correção e muita discussão sobre o que é 
mais importante. 

3.3.4 Detecção e Recuperação 

Uma segunda técnica é a detecção e recuperação. Quan¬ 
do essa técnica é utilizada, o sistema não faz nada exceto 
monitorar as solicitações e as liberações. Cada vez que um 
recurso é solicitado ou liberado, o grafo de recurso é atua¬ 
lizado, e uma verificação é feita para ver se qualquer ciclo 
existe. Se um ciclo existir, um dos processos no ciclo é eli¬ 
minado. Se isso não quebrar o impasse, outro processo é 
eliminado e assim por diante até que o ciclo seja quebrado. 

Um método relativamente mais rudimentar é nem 
mesmo manter o grafo de recurso, mas, em vez disso, veri¬ 
ficar periodicamente se há qualquer processo que foi con¬ 
tinuamente bloqueado por mais que, digamos, 1 hora. Es¬ 
ses processos, então, são eliminados. 

A detecção e recuperação é a estratégia freqüentemente 
utilizada em grandes computadores mainframe, especial¬ 
mente sistemas em lote nos quais eliminar um processo e, 
então, reiniciar é normalmente aceitável. Mas deve-se to¬ 
mar cuidado de restaurar qualquer arquivo modificado ao 
seu estado original e desfazer qualquer outro efeito colate¬ 
ral que possa ter ocorrido. 

3.3.5 Prevenção de Impasses 

A terceira estratégia de impasse é impor restrições con¬ 
venientes para os processos de tal modo que os impasses 
sejam estruturalmente impossíveis. As quatro condições 
declaradas por Coffman e colaboradores (1971) oferecem 
um indício para algumas possíveis soluções. Se pudermos 
assegurar que pelo menos uma dessas condições nunca sej a 
satisfeita, então os impasses serão impossíveis (Havender, 
1968 ). 

Primeiro abordaremos a condição de exclusão mútua. 
Se nenhum recurso fosse atribuído exclusivamente a um 
único processo, nunca teríamos impasses. Entretanto, é 
igualmente claro que permitir dois processos gravar na 
impressora ao mesmo tempo levará ao caos. Fazendo s/wo/ 
da saída da impressora, vários processos podem gerar saí¬ 
da ao mesmo tempo. Nesse modelo, 0 único processo que 
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Figura 3-8 Um exemplo de como ocorre um impasse e de como ele pode ser evitado. 
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realmente solicita a impressora física é o claemon de im¬ 
pressora. Como o daemon nunca solicita qualquer outro 
recurso, podemos eliminar o impasse para a impressora 

Infelizmente, nem todos os dispositivos podem ser en¬ 
viados para o spool (a tabela de processos é um exemplo). 
Além disso, a competição por espaço em disco para fazer 
spool pode levar a um impasse. 0 que aconteceria se dois 
processos preenchessem, cada um, metade do espaço dis¬ 
ponível para spool com saída e nenhum terminasse? Se o 
daemon fosse programado para começar a impressão até 
mesmo antes de toda a saída ser colocada no spool , a im¬ 
pressora poderia ficar desocupada se um processo de saída 
decidisse esperar várias horas após a primeira rajada de 
saída. Por essa razão, os daemons normalmente são pro¬ 
gramados para imprimir somente depois que o arquivo 
completo de saída está disponível. Nenhum processo ja¬ 
mais acabará; então, temos um impasse no disco. 

A segunda das condições declarada por Coffman e co¬ 
laboradores parece mais promissora. Se nos for possível 
prevenir que os processos que seguram recursos esperem 
mais recursos, poderíamos eliminar impasses. Uma ma¬ 
neira de alcançar essa meta é requerer que todos os proces¬ 
sos solicitem todos os seus recursos antes de iniciar a exe¬ 
cução. Se tudo estivesse disponível, o processo seria aloca¬ 
do sempre que necessário e poderia executar até sua con¬ 
clusão. Se um ou mais recursos estivessem ocupados, nada 
seria alocado, e o processo simplesmente esperaria. 

Um problema imediato com essa abordagem é que 
muitos processos não sabem de quantos recursos eles ne¬ 
cessitarão até que tenham começado a executar. Outro pro¬ 
blema é que os recursos não serão utilizados otimamente 
com essa abordagem. Tome, como um exemplo, um pro¬ 
cesso que lê dados de uma fita de entrada, analisa-os du¬ 
rante um hora e, então, grava uma fita de saída assim como 
plota os resultados. Se todos os recursos devessem ser re¬ 
queridos antecipadamente, o processo amarraria a unida¬ 
de de fita de saída e a plotadora durante uma hora. 

Uma maneira ligeiramente diferente de quebrar a con¬ 
dição de segura e espera é requerer que um processo que 
solicita um recurso primeiro libere temporariamente todos 
os recursos atualmente sendo segurados. Somente se a so¬ 
licitação for bem-sucedida ela poderá receber de volta os 
recursos originais. 

Abordar a terceira condição (nenhuma preempção) é 
ainda menos promissor que abordar a segunda. Se a um 
processo obteve acesso a impressora e ele está no meio da 


impressão de sua saída, tomar à força a impressora, por¬ 
que uma plotadora necessária não está disponível, resulta¬ 
rá em uma confusão. 

Restou somente uma condição. A espera circular pode 
ser eliminada de várias maneiras. Uma maneira é simples¬ 
mente ter uma regra que diz que um processo é intitulado 
somente para um único recurso em qualquer momento. 
Se precisar de um segundo, ele deve liberar o primeiro. Para 
um processo que necessita copiar um arquivo enorme de 
uma fita para uma impressora, essa restrição é inaceitável. 

Outra maneira de evitar a espera circular é oferecer uma 
numeração global de todos os recursos, como mostrado na 
Figura 3-9(a). Agora a regra é esta: processos podem soli¬ 
citar recursos sempre que quiserem, mas todas as solicita¬ 
ções devem ser feitas em ordem numérica. Um processo 
pode solicitar primeiro uma impressora e, então, uma uni¬ 
dade de fita, mas não pode solicitar primeiro uma plotado¬ 
ra e, então, uma impressora. 

Com essa regra, o grafo de alocação de recursos nunca 
pode ter círculos. Deixe-nos ver por que isso é verdadeiro 
para o caso de dois processos, na Figura 3-9(b). Podemos 
obter um impasse somente sezl solicita o recurso jeB soli¬ 
cita o recurso i. Supondo que / e j sejam recursos distintos, 
eles terão números diferentes. Se i > j, então A não tem 
permissão para solicitar j. Se i < j, então B não tem per¬ 
missão para solicitar i. De qualquer maneira, o impasse é 
impossível. 

Com múltiplos processos a mesma lógica mantém-se. 
Em cada instante, um dos recursos atribuídos será o mais 
alto. O processo que segura esse recurso nunca pedirá um 
recurso já atribuído. Ele terminará, ou na pior das hipóte¬ 
ses, solicitará recursos numerados ainda mais alto, todos 
os quais estão disponíveis. Por fim, ele terminará e libera¬ 
rá seus recursos. Nesse ponto, algum outro processo segu¬ 
rará o recurso mais alto e também pode terminar. Em re¬ 
sumo, aí existe um cenário em que todos os processos ter¬ 
minam, então, nenhum impasse está presente. 

Uma variação menor desse algoritmo é derrubar o re¬ 
quisito de que os recursos devem ser adquiridos em uma 
seqüência precisamente crescente e simplesmente insistir 
que nenhum processo solicite um recurso mais baixo do 
que aquele que ele já está segurando. Se um processo ini¬ 
cialmente solicitar 9 e 10 e, então, liberar ambos, ele está 
efetivamente iniciando tudo de novo, então, não há ne¬ 
nhuma razão para proibi-lo de agora solicitar o recurso 1. 


1. CD-ROM 

2. Impressora 

3. Plotadora 

4. Unidade de fita 

5. Braço autômato 



(a) 


(b) 


Figura 3-9 (a) Recursos numericamente ordenados, (b) Um grafo de recurso. 
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Condição 

Abordagem 

Exclusão mútua 

Fazer spooi de tudo 

Segura e espera 

Solicitar todos os recursos inicialmente 

Nenhuma preempção 

Tirar os recursos 

Espera circular 

Ordenar os recursos numericamente 


Figura 3-10 Resumo das abordagens para prevenção de impasses. 


Embora ordenar numericamente os recursos elimine o 
problema dos impasses, pode ser impossível descobrir uma 
ordem que satisfaça a todos. Quando os recursos incluem 
entradas na tabela de processos, espaço de spool em disco, 
registros bloqueados de banco de ciados e outros recursos 
abstratos, o número de potenciais recursos e as diferentes 
utilizações podem ser tão grandes que talvez nenhuma or¬ 
denação funcione. 

As várias abordagens para prevenção de impasses são 
resumidas na Figura 3-10. 

3.3.6 Impedimento de Impasses 

Na Figura 3-8 vimos que o impasse não foi evitado pela 
imposição de regras arbitrárias aos processos, mas pela 
análise cuidadosa de cada solicitação de recurso para ver 
se ele poderia ser concedido seguramente. A pergunta sur¬ 
ge: há um algoritmo que sempre pode evitar impasses fa¬ 
zendo a escolha certa todas as vezes? A resposta é um qua¬ 
lificado sim — podemos evitar impasses, mas somente se 
certas informações estiverem disponíveis de antemão. Nes¬ 
ta seção, examinamos maneiras de evitar impasses medi¬ 
ante a alocação cuidadosa de recursos. 

Algoritmo do Banqueiro para um Único 
Recurso 

Um algoritmo de agendamento que pode evitar impas¬ 
ses é creditado a Dijkstra (1965) e conhecido como algo¬ 


ritmo do banqueiro. Ele é modelado na maneira como 
um banqueiro de um pequeno povoado poderia lidar com 
um grupo de clientes para os quais ele concedeu linhas de 
crédito. Na Figura 3-11 (a) vemos quatro clientes, a cada 
um dos quais foi concedido um certo número de unidades 
de crédito (p. ex., 1 unidade é 1K dólares). 0 banqueiro 
sabe que nem todos os clientes precisarão do seu crédito 
máximo imediatamente; então, ele somente reservou 10 
unidades em vez de 22 para atendê-los. (Nesta analogia, os 
clientes são os processos, as unidades são, digamos, as uni¬ 
dades de fita, e o banqueiro é o sistema operacional.) 

Os clientes iniciam seus respectivos negócios, solicitando 
empréstimos de vez em quando. Em um certo momento, a 
situação é como a mostrada na Figura 3-H(b). Uma lista 
de clientes mostrando o dinheiro já emprestado (unidades 
de fita já atribuídas) e o crédito máximo disponível (nú¬ 
mero máximo de unidades de fita necessárias de uma vez 
mais tarde) é chamada estado do sistema com relação à 
alocação de recurso. 

Um estado é conhecido como seguro se existir uma 
seqüência de outros estados que leva a todos os clientes a 
solicitarem empréstimos até seus limites de crédito (todos 
os processos obtêm todos os seus recursos e terminam.) O 
estado da Figura 3-11 (b) é seguro porque, com duas uni¬ 
dades, o banqueiro pode adiar qualquer solicitação, exceto 
a de Marvin, deixando, assim, Marvin terminar e liberar 
todos os seus quatro recursos. Com quatro unidades em 
mãos, o banqueiro pode permitir que Suzanne ou Bárbara 
tenham as unidades necessárias, etc. 


Usado Máximo Usado Máximo Usado Máximo 



Disponível: 10 Disponível: 2 Disponível: 1 


(a) (b) (c) 

Figura 3-11 Três estados de alocação de recursos: (a) Seguro, (b) Seguro, (c) Inseguro. 
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Considere o que aconteceria se uma solicitação de Bar¬ 
bara para mais uma unidade fosse concedida na Figura 3- 
11 (b). Teríamos a situação da Figura 3-11 (c), que é inse¬ 
gura. Se todos os clientes repentinamente solicitassem seus 
empréstimos máximos, o banqueiro não poderia satisfazer 
nenhum deles e teríamos um impasse. Um estado insegu¬ 
ro não conduz necessariamente a um impasse, desde que 
um cliente pode não precisar de toda a linha de crédito 
disponível, mas o banqueiro não pode confiar nesse com¬ 
portamento. 

Portanto, o algoritmo do banqueiro serve para consi¬ 
derar cada solicitação conforme ela ocorre e ver se o fato 
de atendê-la conduz a um estado seguro. Se conduzir, a 
solicitação é atendida: caso contrário, é postergada. Para 
ver se um estado é seguro, o banqueiro verifica se tem re¬ 
cursos suficientes para satisfazer o cliente o mais perto do 
máximo exigido por esse cliente. Se conseguir, ele assume 
que esses empréstimos serão pagos, e o cliente agora mais 
perto do seu limite é verificado e assim por diante. Se todos 
os empréstimos eventualmente puderem ser pagos, o esta¬ 
do é seguro e a solicitação inicial pode ser concedida. 

Trajetórias de Recursos 

0 algoritmo acima foi descrito em termos de uma úni¬ 
ca classe de recursos (p. ex., somente unidades de fita ou 
somente impressoras, mas não um pouco de cada). Na Fi¬ 
gura 3-12, vemos um modelo para lidar com dois proces¬ 
sos e com dois recursos, por exemplo, uma impressora e 
uma plotadora. O eixo horizontal representa o número de 
instruções executadas pelo processo A O eixo vertical re¬ 
presenta o número de instruções executadas pelo processo 
B. Em I h A solicita uma impressora; em I 2 , ele precisa de 
uma plotadora. A impressora e a plotadora são liberadas 


em / 3 e / 4 , respectivamente. 0 processo B precisa da plota¬ 
dora de I 5 até /- e da impressora de 4 até / g . 

Cada ponto no diagrama representa um estado de união 
de dois processos. Inicialmente, o estado está em p, com 
nenhum processo tendo executado qualquer instrução. Se 
o agendador escolher executar A primeiro, alcançamos o 
ponto q em que A executou um certo número de instru¬ 
ções, mas B não executou nenhuma. No ponto q, a trajetó¬ 
ria torna-se vertical que o agendador escolheu executar B. 
Com um único processador, todos os caminhos devem ser 
horizontais ou verticais, nunca diagonais. Além disso, o 
movimento é sempre para o norte ou para o leste, nunca 
para o sul ou para o oeste (os processos não podem execu¬ 
tar para trás). 

Quando A cruza a linha 4 no caminho de r para s, ele 
solicita e lhe é concedida a impressora. Quando B alcança 
o ponto t, ele solicita a plotadora. 

As regiões sombreadas são sobremaneira interessantes. 
As regiões com linhas inclinadas de sudoeste para nordeste 
representam que dois processos têm a impressora. A regra 
da exclusão mútua torna impossível entrar nessa região. 
De maneira semelhante, a região sombreada no sentido 
contrário representa que os dois processos têm a plotadora 
e é igualmente impossível. 

Se o sistema jamais entrar na caixa delimitada por 4 e 
/ 2 nos lados e / 5 e 4, nas partes superior e inferior, ele acaba¬ 
rá em um impasse quando chegar à interseção de 4 e 4- 
Nesse ponto, A está solicitando a plotadora, e B está solici¬ 
tando a impressora, mas ambas j á foram atribuídas. A cai¬ 
xa inteira é insegura e não se deve entrar nela. No ponto A 
a única coisa segura a fazer é executar o processo A até 
chegar a/ 4 . Além desse ponto, qualquer trajetória até u ser¬ 
virá. 



Impressora 

-«-Plotadora 


Figura 3-12 Duas trajetórias de recurso de processo. 
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O Algoritmo do Banqueiro para Múltiplos 
Recursos 

Esse modelo gráfico é difícil de aplicar para o caso ge¬ 
ral de um número arbitrário de processos e para um nú¬ 
mero arbitrário de classes de recursos, cada um com múl¬ 
tiplas instâncias (p. ex., duas plotadoras, três unidades de 
fita). Entretanto, o algoritmo do banqueiro pode ser gene¬ 
ralizado para fazer o trabalho. A Figura 3-13 mostra como 
ele funciona. 

Na Figura 3-13 vemos duas matrizes. A da esquerda 
mostra quanto de cada recurso está atualmente atribuído 
a cada um dos cinco processos. A matriz à direita mostra 
quantos recursos cada processo ainda precisa de modo que 
possa completar-se. Como no caso de um recurso único, os 
processos devem declarar suas necessidades totais de recur¬ 
so antes de executar, para que o sistema possa calcular a 
matriz da direita em cada passo. 

Os três vetores à direita da figura mostram os recursos 
existentes, E, os recursos possuídos. R e os recursos dispo¬ 
níveis, A, respectivamente. A partir de E vemos que o siste¬ 
ma tem seis unidades de fita, três plotadoras, quatro im¬ 
pressoras e dois CD-ROMs. Desses, cinco unidades de fita, 
três plotadoras, duas impressoras e dois CD-ROMs atual¬ 
mente estão atribuídos. Esse fato pode ser visto adicionan¬ 
do-se as quatro colunas de recursos na matriz esquerda. O 
vetor de recursos disponíveis é simplesmente a diferença 
entre o que o sistema tem e o que está atualmente em uti¬ 
lização. 

0 algoritmo para verificar se um estado é seguro agora 
pode ser declarado. 

1. Procure uma linha, R, cujas necessidades de re¬ 
cursos não-atendidas são todas menores que ou 
iguais a A. Se não existir essa linha, o sistema aca¬ 
bará em um impasse uma vez que nenhum pro¬ 
cesso pode executar até sua conclusão. 

2. Suponha que o processo da linha escolhida solici¬ 
te todos os recursos que precisa (o que é garantido 


que é possível) e termine. Marque esse processo 
como terminado e adicione todos os seus recursos 
ao vetor A. 

3. Repita os passos 1 e 2 até que todos os processos 
estejam marcados como terminado, caso em que 
o estado inicial era seguro, ou até que um impasse 
ocorra, caso em que não era seguro. 

Se vários processos são elegíveis para serem escolhidos 
no passo 1, não importa qual é selecionado: o pool de re¬ 
cursos aumenta, ou no pior caso, permanece o mesmo. 

Agora voltemos ao exemplo da Figura 3-13- O estado 
atual é seguro. Suponha que o processo B agora solicite 
uma impressora. Essa solicitação pode ser concedida por¬ 
que o estado resultante ainda é seguro (o processo D pode 
terminar, e, então, dar vez aos processos A ou E, seguidos 
pelo resto). 

Agora imagine que depois de dar a B uma das duas 
impressoras que restaram, E queira ter a última impresso¬ 
ra. Conceder essa solicitação reduziria o vetor dos recursos 
disponíveis para (1 0 0 0), o que conduz a um impasse. É 
claro que a solicitação de E não pode ser satisfeita imedia¬ 
tamente e deve ser adiada temporariamente. 

Esse algoritmo foi publicado pela primeira vez por Di- 
jkstra em 1965. Desde então, quase todos os livros sobre 
sistemas operacionais descreveram-no em detalhe. Inume¬ 
ráveis trabalhos foram escritos sobre vários aspectos dele. 
Infelizmente, poucos autores tiveram a coragem de indi¬ 
car que embora na teoria o algoritmo seja maravilhoso, 
na prática ele é essencialmente inútil porque os processos 
raramente sabem quais são suas necessidades máximas de 
recursos previamente. Além do mais, o número de proces¬ 
sos não é fixo. mas dinamicamente variável conforme no¬ 
vos usuários se conectam e se desconectam. Além disso, os 
recursos que foram considerados como disponíveis repen¬ 
tinamente podem desaparecer (unidades de fita podem 
quebrar). 

Em resumo, os esquemas descritos anteriormente sob o 
nome "prevenção" são muito restritivos, e o algoritmo des- 
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Figura 3-13 O algoritmo do banqueiro com múltiplos recursos. 
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crito aqui como "impedimento" requer informações que 
normalmente não estão disponíveis. Se você pode imagi¬ 
nar um algoritmo de propósito geral que faça o trabalho 
na prática tão bem quanto na teoria, escreva-o e envie-o a 
uma publicação de ciência da computação. 

Para aplicações específicas, são conhecidos muitos al¬ 
goritmos excelentes de propósito especial. Como um exem¬ 
plo, em muitos sistemas de banco de dados, uma operação 
que ocorre freqüentemente é requisitar bloqueios em vári¬ 
os registros e, então, atualizar todos os registros bloquea¬ 
dos. Quando múltiplos processos estão executando ao mes¬ 
mo tempo, há um perigo real de impasse. 

A abordagem freqüentemente utilizada é chamada blo¬ 
queio de duas fases. Na primeira fase, o processo tenta 
bloquear todos os registros que precisa, um por vez. Se tiver 
sucesso, ele executa suas atualizações e libera os bloque¬ 
ios. Se algum registro já estiver bloqueado, ele libera os 
bloqueios que ele já tem e simplesmente começa tudo de 
novo. Em um certo sentido, essa abordagem é semelhante 
a solicitar todos os recursos necessários previamente ou pelo 
menos antes de qualquer coisa irrevogável ser feita. 

Entretanto, essa estratégia não é aplicável de maneira 
geral. Em sistemas de tempo real e em sistemas de controle 
de processos, por exemplo, não é aceitável simplesmente 
terminar um processo no meio do caminho porque um re¬ 
curso não está disponível e começar tudo de novo. Nem é 
aceitável começar tudo de novo se o processo leu ou gra¬ 
vou mensagens na rede, atualizou arquivos ou fez qual¬ 
quer outra coisa que não pode ser repetida com segurança. 
0 algoritmo funciona somente nas situações em que o pro¬ 
gramador muito cuidadosamente organizou as coisas de 
tal modo que o programa pode ser interrompido em qual¬ 
quer ponto durante a primeira fase e reiniciado. Infeliz- 
mente, nem todos os aplicativos podem ser estruturados 
dessa maneira. 


3.4 VISÃO GERAL DE E/S NO MINIX 

A E/S do MINIX é estruturada como mostrado na Figura 
3-6. As quatro primeiras camadas superiores dessa figura 
correspondem à estrutura de quatro camadas do minix 
mostrada na Figura 2-26. Nas seções a seguir, veremos um 
resumo de cada uma das camadas, com ênfase nos drivers 
de dispositivo. 0 tratamento de interrupções foi estudado 
no capítulo anterior, e a E/S independente do dispositivo 
será discutida quando abordarmos o sistema de arquivos, 
no Capítulo. 5. 

3.4.1 Manipuladores de Interrupções 
no MINIX 

Muitos dos drivers de dispositivo iniciam algum dispo¬ 
sitivo de E/S e, então, bloqueiam, esperando uma mensa¬ 
gem chegar. Essa mensagem nonnalmente é gerada pelo 
manipulador de interrupções do dispositivo. Outros drivers 
de dispositivo não iniciam nenhuma E/S física (p. ex., ler 


de um disco de RAM e gravar em um dispositivo de exibição 
mapeado em memória), não utilizam interrupções e não 
esperam uma mensagem de um dispositivo de E/S. No ca¬ 
pítulo anterior, o mecanismo por meio do qual as interrup¬ 
ções geram mensagens e causam comutação de tarefas foi 
apresentado em grande detalhe e não falaremos mais sobre 
ele aqui. Mas os manipuladores de interrupções podem fa¬ 
zer mais do que apenas gerar uma mensagem. Freqüente¬ 
mente eles também fazem algum trabalho no processamen¬ 
to de entrada e de saída de baixo nível. Discutiremos isso de 
uma maneira geral aqui e, então, retornaremos aos deta¬ 
lhes quando abordarmos o código para vários dispositivos. 

Para dispositivos de disco, a entrada e a saída é geral¬ 
mente uma questão de comandar um dispositivo para exe¬ 
cutar sua operação e, então, esperar até que a operação 
esteja completa. A controladora de disco faz a maior parte 
do trabalho, e muito pouco é exigido do manipulador de 
interrupções. Vimos que o manipulador de interrupções 
inteiro para a tarefa de disco rígido consiste em somente 
três linhas de código, com a única operação de E/S sendo a 
leitura de um único byte para determinar o status da con¬ 
troladora. Nossa vida seria simples de fato se todas as inter¬ 
rupções pudessem ser tratadas assim tão facilmente. 

Entretanto, às vezes, há mais coisas para o manipula¬ 
dor de baixo nível fazer. 0 mecanismo de passagem de 
mensagens tem um custo. Quando uma interrupção pode 
ocorrer freqüentemente mas a quantidade de E/S tratada 
pela interrupção é pequena, pode valer a pena fazer o pró¬ 
prio manipulador trabalhar um pouco mais e adiar o en¬ 
vio de uma mensagem para a tarefa até uma interrupção 
subseqüente, quando há mais para a tarefa fazer. 0 MINIX 
trata interrupções do relógio dessa maneira. Em muitos 
tiques de relógio há muito pouco a ser feito, exceto manter 
o tempo. Isso pode ser feito sem enviar uma mensagem à 
própria tarefa de relógio. 0 manipulador de relógio incre¬ 
menta uma variável, apropriadamente chamada pending_ 
ticks. 0 tempo atual é a soma do tempo registrado quando 
a própria tarefa de relógio executou pela última vez mais o 
valor de pending_ticks. Quando a tarefa de relógio recebe 
uma mensagem e acorda, ela adiciona pendingjicks à 
sua variável principal de monitoração do tempo e, então, 
zera pendingjicks. 0 manipulador de interrupções do re¬ 
lógio examina algumas outras variáveis e envia uma men¬ 
sagem à tarefa de relógio somente quando detecta que a 
tarefa tem trabalho real a fazer, como entregar um alarme 
ou agendar um novo processo para executar. Ele também 
pode enviar uma mensagem à tarefa de terminal. 

Na tarefa de terminal, vemos outra variação do tema 
manipulador de interrupções. Essa tarefa trata vários tipos 
diferentes de hardware, incluindo o teclado e as linhas RS- 
232. Cada um desses têm seu próprio manipulador de in¬ 
terrupções. 0 teclado ajusta-se exatamente na descrição de 
um dispositivo em que pode haver relativamente pouca E/ 
S a fazer em resposta a cada interrupção. Em um PC, uma 
interrupção ocorre cada vez que uma tecla é pressionada 
ou é liberada. Isso inclui teclas especiais como as teclas 
SHIFT e CTRL. Mas, se as ignoramos por um momento, 
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poderemos dizer que, na média, metade de um caractere é 
recebido por interrupção. Como não há muito o que a ta¬ 
refa de terminal possa fazer com metade um caractere, faz 
sentido enviar-lhe uma mensagem somente quando algo 
que vale a pena pode ser realizado. Examinaremos os de¬ 
talhes mais tarde; por enquanto, diremos apenas que o ma¬ 
nipulador de interrupções de teclado faz a leitura de baixo 
nível dos dados do teclado e, então, filtra eventos que pode 
ignorar, como a liberação de uma tecla comum. (A libera¬ 
ção de uma tecla especial, p. ex., a tecla SHIFT, não pode 
ser ignorada.) Então, os códigos que representam todos os 
eventos não-ignorados são colocados em uma fila para pos¬ 
terior processamento pela própria tarefa de terminal. 

O manipulador de interrupções de teclado difere do 
paradigma simples que apresentamos do manipulador de 
interrupções que envia uma mensagem para sua tarefa 
associada, porque este manipulador de interrupções não 
envia absolutamente nenhuma mensagem. Em vez disso, 
quando adiciona um código à fila, ele modifica uma vari¬ 
ável, ttyjimeout, que é lida pelo manipulador de inter¬ 
rupções do relógio. Quando uma interrupção não muda a 
fila, ttyjimeout também não é mudado. No próximo ti¬ 
que de relógio, o manipulador de relógio envia uma men¬ 
sagem à tarefa de terminal se houver alterações na fila. 
Outros manipuladores de interrupções do tipo terminal, por 
exemplo, aqueles para as linhas RS-232, funcionam da 
mesma maneira. Uma mensagem para tarefa de terminal 
chegará logo depois que um caractere for recebido, mas 
uma mensagem não é necessariamente gerada para cada 
caractere quando os caracteres estão chegando rapidamen¬ 
te. Vários caracteres podem acumular e, então, podem ser 
processados em resposta a uma única mensagem. Além 
disso, todos os dispositivos terminais são verificados cada 
vez que uma mensagem é recebida pela tarefa de terminal. 

3.4.2 Drivers de Dispositivo no MINIX 

Para cada classe de dispositivo de E/S presente em um 
sistema MiNix, uma tarefa de E/S ( driver de dispositivo) 
diferente está presente. Esses drivers são processos comple¬ 
tos, cada um com seus próprios estados, registradores, pi¬ 
lhas e assim por diante. Os drivers de dispositivo comuni¬ 
cam-se entre si (onde necessário) e com o sistema de ar¬ 
quivos utilizando o mecanismo-padrão de passagem de 
mensagens utilizado por todos os processos do MINIX. Dri¬ 
vers de dispositivo simples estão escritos como arquivos- 
fonte únicos, como clock.c. Para outros drivers , como os 
para o disco de RAM, o disco rígido e o disquete, há um 
arquivo-fonte suportando cada tipo de dispositivo, assim 
como um conjunto de rotinas comuns em driver. c para 
suportar todos os diferentes tipos de hardware. Em um sen¬ 
tido, isso divide o nível de driver de dispositivo da Figura 3- 
6 em dois subníveis. Essa separação das partes do software 
dependente do hardware e independente do hardware faci¬ 
lita a adaptação para uma variedade de configurações de 
hardware. Embora algum código-fonte em comum seja 
utilizado, o driver para cada tipo de disco executa como 


um processo separado, para suportar rápidas transferênci¬ 
as de dados. 

De modo semelhante, o código-fonte do driver de ter¬ 
minal é organizado com o código independente do har¬ 
dware em tty.c e o código-fonte para suportar dispositivos 
diferentes, tal como consoles mapeados de memória, te¬ 
clado, linhas seriais e pseudoterminais em arquivos sepa¬ 
rados. Nesse caso, entretanto, um único processo suporta 
todos os diferentes tipos de dispositivo. 

Para grupos de dispositivos como dispositivos de disco e 
de tenninais, para os quais pode haver vários arquivos-fonte, 
também há arquivos de cabeçalho. Driver.h suporta todos 
os drivers de dispositivo de bloco. Tty.h oferece definições 
comuns para todos os dispositivos terminais. 

A principal diferença entre drivers de dispositivo e ou¬ 
tros processos é que os drivers de dispositivo são vincula¬ 
dos juntos no kernel e, assim, todos compartilham um es¬ 
paço comum de endereço. Como resultado, se vários dri¬ 
vers de dispositivo utilizarem um procedimento comum, 
somente uma cópia será vinculada no código binário do 
MINIX. 

Esse projeto é altamente modular e moderadamente 
eficiente. É também um dos poucos lugares onde o mintx 
difere do UNIX de uma maneira essencial. No MINIX um 
processo lê um arquivo enviando uma mensagem para o 
processo de sistema de arquivos. O sistema de arquivos, por 
sua vez, pode enviar uma mensagem para o driver de dis¬ 
co solicitando que ele leia o bloco necessário. Essa seqüên- 
cia (ligeiramente simplificada em relação ao que acontece 
na realidade) é mostrada na Figura 3-l4(a). Fazendo es¬ 
sas interações via mecanismo de mensagens, forçamos vá¬ 
rias partes do sistema a interfacear de maneiras padroni¬ 
zadas com outras partes. Contudo, colocando todos os dri¬ 
vers de dispositivo no espaço de endereço do kernel, eles 
têm acesso fácil à tabela de processos e a outras estruturas 
de dados-chave quando necessário. 

No UNIX todos os processos têm duas partes: uma parte 
no espaço do usuário e uma parte no espaço do kernel, 
como mostrado na Figura 3-l4(b) Quando uma chamada 
de sistema é feita, o sistema operacional alterna da parte 
no espaço do usuário para a parte no espaço do kernel de 
uma maneira algo mágica. Essa estrutura é um remanes¬ 
cente do projeto do MULTICS, na qual a comutação era ape¬ 
nas uma chamada de procedimento comum, em vez de 
uma interrupção seguida pelo salvamento do estado da 
parte do usuário, como é no UNIX. 

Os drivers de dispositivo no UNIX são simplesmente pro¬ 
cedimentos do kernel que são chamados pela parte no es¬ 
paço de kernel do processo. Quando um driver precisa es¬ 
perar uma interrupção, ele chama um procedimento do 
kernel que o coloca para dormir até que algum manipula¬ 
dor de interrupções acorde-o. Note que é o próprio processo 
de usuário que está sendo colocado para dormir aqui, por¬ 
que as partes do kernel e do usuário são na realidade par¬ 
tes diferentes do mesmo processo. 

Entre os projetistas de sistema operacional, argumen¬ 
tos sobre os méritos dos sistemas monolíticos, como no UNIX, 
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independentes 



A parte do espaço do usuário 
chama a parte do espaço do 
kernel por interrupção ( trapping ). 
O sistema de arquivos chama o 
driver de dispositivo como um 
procedimento. O sistema 
operacional inteiro é parte 
de cada processo 


(a) 


(b) 


Figura 3-14 Duas maneiras de estruturar a comunicação sistema-usuário. 


versus sistemas estruturados por processos, como no MI- 
Nix, são intermináveis. A abordagem do minix é melhor 
estruturada (mais modular), tem interfaces mais limpas 
entre as partes e estende-se facilmente para sistemas distri¬ 
buídos em que os vários processos executam em computa¬ 
dores diferentes. A abordagem no UNIX é mais eficiente, 
porque as chamadas de procedimento são muito mais rá¬ 
pidas que o envio de mensagens. 0 MINIX foi dividido em 
muitos processos porque acreditamos que com computa¬ 
dores pessoais cada vez mais poderosos disponíveis, valeria 
a pena tornar o sistema ligeiramente mais lento para obter 
uma estrutura de software mais limpa. Mas leve em conta 
que muitos projetistas de sistema operacional não com¬ 
partilham dessa crença. 

Neste capítulo, discutimos drivers para disco de RAM, 
disco rígido, relógio e terminal. A configuração-padrão do 
MINIX também inclui drivers para disquete e para impres¬ 
sora, que não são discutidos em detalhe. A distribuição pa¬ 
drão do MINIX contém o código-fonte de drivers adicionais 
para linhas seriais RS-232, uma interface SCSI, CD-ROM, 
adaptador Ethernet e placa de som. Esses podem ser inclu¬ 
ídos recompilando o MINIX. 

Todas essas tarefas interfaceiam com outras partes do 
sistema minix da mesma maneira: mensagens de solicita¬ 
ção são enviadas para as tarefas. As mensagens contêm uma 
variedade de campos para armazenar o código de opera¬ 
ção (p. ex., read ou write) e seus parâmetros. Uma tarefa 


tenta atender uma solicitação e retorna uma mensagem 
de resposta. 

Para dispositivos de bloco, os campos das mensagens 
de solicitação e de resposta são mostrados na Figura 3-15. 
A mensagem de solicitação inclui o endereço de uma área 
de buffer que contém os dados a serem transmitidos ou na 
qual são esperados dados recebidos. A resposta inclui as 
informações de status para que o processo solicitante possa 
verificar se sua solicitação foi adequadamente executada. 
Os campos para os dispositivos de caractere são basicamente 
semelhantes mas podem variar ligeiramente de tarefa para 
tarefa. As mensagens para a tarefa de relógio, por exemplo, 
contêm tempos, e as mensagens para a tarefa de terminal 
podem conter o endereço de uma estrutura de dados que 
especifica todos os muitos aspectos configuráveis de um 
terminal, como os caracteres utilizados pelas funções de 
edição erose-chamcter (apaga caractere) e kill-line (eli¬ 
mina linha). 

A função de cada tarefa é aceitar solicitações de outros 
processos, normalmente o sistema de arquivos, e executá- 
las. Todas as tarefas de dispositivo de bloco foram escritas 
para receber uma mensagem, executá-la e enviar uma res¬ 
posta. Entre outras coisas, essa decisão significa que essas 
tarefas são estritamente seqüenciais e não contém nenhu¬ 
ma multiprogramação interna, para mantê-las simples. 
Quando uma solicitação de hardware é feita, a tarefa faz 
uma operação RKCEIVE especificando que está interessada 
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apenas em aceitar mensagens de interrupções, não novas 
solicitações para trabalhar. Quaisquer novas mensagens de 
solicitação são apenas mantidas esperando ate' que o tra¬ 
balho atual tenha sido feito (princípio do rendez-vous). A 
tarefa de terminal é ligeiramente diferente, uma vez que 
uma única tarefa serve a vários dispositivos. Assim, é possí¬ 
vel aceitar uma nova solicitação para entrada do teclado 
enquanto uma solicitação para ler uma linha serial ainda 
está sendo atendida. Contudo, para cada dispositivo uma 
solicitação deve ser completada antes de iniciar uma nova. 

0 programa principal para cada driver de dispositivo 
de bloco é estruturalmente o mesmo e é delineado na Fi¬ 
gura 3-16. Quando o sistema inicia pela primeira vez, cada 
um dos drivers é inicializado, por sua vez, para dar a cada 
um a chance de inicializar tabelas internas e coisas seme¬ 
lhantes. Então, a tarefa de cada driver bloqueia, tentando 
obter uma mensagem. Quando uma mensagem chega, a 
identidade do processo que chama é salva, e o procedimento 
é chamado para executar o trabalho, com um procedimento 
diferente invocado para cada operação disponível. Depois 
que o trabalho terminou, uma resposta é enviada de volta 
para o processo que chamou, e a tarefa, então, volta para o 
topo do laço para esperar a próxima solicitação. 

Cada um dos procedimentos dev_xxx trata uma das 
operações de que o driver é capaz. Ele retorna um código 
de status, informando o que aconteceu. 0 código de status, 
incluído na mensagem de resposta como o campo 


REP_STATUS. é a contagem de bytes transferidos (zero ou 
positiva) se tudo deu certo, ou o número do erro (negati¬ 
vo) se algo deu errado. Essa contagem pode diferir do nú¬ 
mero solicitado de bytes. Quando o fim de um arquivo é 
alcançado, o número de bytes disponível pode ser inferior 
ao número solicitado. Em terminais, no máximo uma li¬ 
nha é retornada, mesmo que a contagem solicitada seja 
maior. 

3.4.3 Software de E/S Independente de 
Dispositivo no MIMX 

No MiNix o processo do sistema de arquivos contém todo 
o código de E/S independente de dispositivo. 0 sistema de 
E/S está tão intimamente relacionado com o sistema de 
arquivos que eles foram fundidos em um processo. As fun¬ 
ções realizadas pelo sistema de arquivos são mostradas na 
Figura 3-5, exceto pela solicitação e pela liberação de dis¬ 
positivos dedicados, que não existem no minix como ele 
está atualmente configurado. Mas elas podem facilmente 
ser adicionadas aos drivers de dispositivo relevantes se a 
necessidade surgir no futuro. 

Além do tratamento da interface com os drivers, buffe- 
rízação e alocação de blocos, o sistema de arquivos tam¬ 
bém trata da proteção e de gerenciamento de diretórios, 
nós-i e sistemas de arquivos montados. Ele será abordado 
em detalhe no Capítulo 5. 


Solicitações 

Campo 

Tipo 

Significado 

m.m_type 

int 

Operação solicitada 

m.DEVICE 

int 

Dispositivo secundário a utilizar 

m.PROC_NR 

int 

Processo solicitando a E/S 

m.COUNT 

int 

Contagem de bytes ou código ioctl 

m. POSITION 

long 

Posição no dispositivo 

m. ADRESS 

char* 

Endereço dentro do processo solicitante 


Respostas 

Campo 

Tipo 

Significado 

m.m_type 

int 

Sempre TASK_REPLY 

m.PROC_REC_NR 

int 

0 mesmo que PROC_NR na solicitação 

m.REP_STATUS 

Int 

Bytes transferidos ou número do erro 


Figura 3-15 Os campos das mensagens enviadas pelo sistema de arquivos para os drivers de dispositivo de 
bloco e os campos das respostas enviadas de volta. 
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message mess; 


buffer de mensagem */ 


void io_task() { 

initializeQ; /* feito só uma vez, durante a inicialização do sistema */ 

while (TRUE) { 

receive(ANY, &mess); /* espera uma solicitação para trabalhar */ 

caller = mess.source; /* processo de quem a mensagem veio */{ 

switch(mess.type) { 

case READ: rcode = dev_read(&mess); break; 
caseWRITE: rcode = dev_write(&mess), break; 

/* Outros casos entram aqui, incluindo OPEN, CLOSE e IOCTL*/ 
default: rcode = ERROR; 


} 

mess.type = TASK_REPLY; 

mess.status = rcode; /* código de resultado */ 

send(caller, &mess); /* envia de volta a mensagem de resposta para o processo */ 

} 

} 


Figura 3-16 Esboço do procedimento principal de uma tarefa de E/S. 


3.4.4 Software de E/S no Nível de 
Usuário no MINIX 

0 modelo geral delineado anteriormente neste capítu¬ 
lo também se aplica aqui. Procedimentos de biblioteca es¬ 
tão disponíveis para fazer chamadas de sistema e para to¬ 
das as funções de C exigidas pelo padrão POSIX, como as 
funções de formatação de entrada e de saída printf zscanf. 
A configuração-padrão do MINIX contém um daemon para 
spool, Ipd, que idzspool e imprime arquivos passados para 
ele pelo comando lp. A distribuição padrão do MINIX con¬ 
tém diversos daemons que suportam várias funções de rede. 
As operações de rede requerem algum suporte do sistema 
operacional que não é parte do MINIX na configuração des¬ 
crita neste livro, mas o minix pode ser facilmente recompi¬ 
lado para adicionar o servidor de rede. Ele executa na mes¬ 
ma prioridade que o gerenciador de memória e o sistema 
de arquivos e, como eles, executa como um processo de 
usuário. 

3-4.5 Manipulação de Impasses no 

MINIX 

Fiel à sua herança, o MINIX segue o mesmo caminho 
que o UNIX com relação a impasses: ele apenas ignora o 
problema. O MINIX não contém dispositivos dedicados de 
E/S, embora se alguém quisesse pendurar uma unidade de 
fita DAT padrão da indústria em um PC, fazer o software 
para isso não representaria qualquer problema especial. 
Em resumo, o único lugar em que os impasses podem ocor¬ 
rer são com os recursos implicitamente compartilhados, 
como as entradas da tabela de processos, as entradas da 
tabela de nós-i e assim por diante. Nenhum dos algoritmos 
de impasse conhecidos pode lidar com recursos como esses 
que não são solicitados explicitamente. 

Realmente, o que foi dito acima não é estritamente ver¬ 
dadeiro. Aceitar o risco que processos de usuário poderiam 


cair em um impasse é uma coisa, mas dentro do próprio 
sistema operacional há alguns lugares em que se tomou 
um cuidado considerável para evitar problemas. O princi¬ 
pal é a interação entre o sistema de arquivos e o gerencia¬ 
dor de memória. 0 gerenciador de memória envia mensa¬ 
gens para o sistema de arquivos ler o arquivo binário (pro¬ 
grama executável) durante uma chamada de sistema F.XEC, 
assim como em outros contextos. Se o sistema de arquivos 
não estiver desocupado quando o gerenciador de memória 
estiver tentando enviar para ele, o gerenciador de memória 
será bloqueado. Se o sistema de arquivos, então, precisasse 
tentar enviar uma mensagem para o gerenciador de me¬ 
mória, ele também descobriria que o rendez-vous falhou 
e bloquearia, levando a um impasse. 

Esse problema foi evitado construindo o sistema de tal 
maneira que o sistema de arquivos nunca envia as mensa¬ 
gens d ^solicitação para o gerenciador de memória, somente 
respostas , com uma pequena exceção. A exceção é que ao 
iniciar, o sistema de arquivos informa o tamanho do disco 
de RAM para o gerenciador de memória, que seguramente 
está esperando a mensagem. 

É possível bloquear dispositivos e arquivos mesmo sem 
suporte do sistema operacional. Um nome de arquivo pode 
servir como uma variável verdadeiramente global, cuja 
presença ou ausência pode ser notada por todos os outros 
processos. Um diretório especial, usr/spool/locks/, está nor¬ 
malmente presente nos sistemas MINIX, como na maioria 
dos sistemas UNIX, onde os processos podem criar arqui¬ 
vos de bloqueio, para marcar qualquer recurso que eles 
estejam utilizando. O sistema de arquivos MINIX também 
suporta o estilo de bloqueio de arquivo aconselhável do 
POSIX. Mas nenhum desses mecanismos é imposto. Eles 
dependem do bom comportamento dos processos e não há 
nada para impedir que um programa utilize um recurso 
que está bloqueado por outro processo. Isso não é exata¬ 
mente a mesma coisa que preempção do recurso, porque 
não impede o primeiro processo de tentar continuar sua 
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utilização do recurso. Em outras palavras, não há exclu¬ 
são mútua. 0 resultado de tal ação por um processo mal- 
comportado é provavelmente uma confusão, mas não re¬ 
sulta em nenhum impasse. 

3.5 DISPOSITIVOS DE BLOCO NO 
MINIX 

Nas seções a seguir, retornaremos aos drivers de dispo¬ 
sitivo, o tema principal deste capitulo e estudaremos vários 
deles detalhadamente. 0 mintx suporta vários dispositivos 
de bloco diferentes. Então começaremos discutindo os as¬ 
pectos comuns a todos os dispositivos de bloco. Discutire¬ 
mos o disco de RAM, o disco rígido e o disquete. Cada um 
desses é interessante por uma razão diferente. 0 disco de 
RAM é um bom exemplo para estudar porque tem todas as 
propriedades dos dispositivos de bloco em geral, exceto a 
E/S real — porque o “disco” é, na realidade, somente uma 
parte da memória. Essa simplicidade toma-o um bom ponto 
de partida. 0 disco rígido mostra como deve ser um driver 
de disco real. Poderia esperar-se que o disquete fosse mais 
fácil de suportar que o disco rígido mas, na realidade, não 
é. Não discutiremos todos os detalhes do disquete, mas in¬ 
dicaremos várias das complicações encontradas no driver 
de disquete. 

Após a discussão de drivers de bloco, discutiremos ou¬ 
tras classes de driver. O relógio é importante porque cada 
sistema tem um e porque é completamente diferente de 
todos os outros drivers. É também de interesse como uma 
exceção à regra de que todos dispositivos são de bloco ou 
de caractere, porque não se ajusta em nenhuma dessas ca¬ 
tegorias. Por fim, discutiremos o driver de terminal, que é 
importante em todos sistemas e, além disso, é um bom 
exemplo de driver de dispositivo de caractere. 

Cada uma dessas seções descreve o hardware relevante, 
os princípios de software por trás do driver , uma visão ge¬ 
ral da implementação e o código em si. Essa estrutura tor¬ 
na a leitura dessas seções útil mesmo para aqueles leitores 
que não estão interessados nos detalhes do código em si. 

3-5.1 Visão Geral de Drivers de 
Dispositivo de Bloco no minix 

Mencionamos anteriormente que os procedimentos 
principais de todas as tarefas de E/S têm uma estrutura 
similar. 0 minix sempre tem pelo menos três tarefas de dis¬ 
positivo de bloco (o driver de disco de RAM, o driver de 
disquete e um entre vários drivers de disco rígido possí¬ 
veis) compiladas no sistema. Além disso, uma tarefa de CD- 
ROM e um driver SCSI (Small Computer Standard Inter¬ 
face) pode ser compilado, no caso de suporte para tais dis¬ 
positivos ser necessário. Embora o driver para cada um 
desses execute como um processo independente, o fato que 
todos eles são compilados como parte do executável do ker- 
nel torna possível compartilhar uma quantidade conside¬ 


rável de código, especialmente os procedimentos utilitári¬ 
os. 

Cada driver de dispositivo de bloco precisa de alguma 
inicialização, naturalmente. 0 driver de disco de RAM pre¬ 
cisa reservar alguma memória, o driver de disco rígido pre¬ 
cisa determinar os parâmetros do hardware de disco rígido 
e assim por diante. Todos os drivers de disco são chamados 
individualmente para inicialização específica de hardwa¬ 
re, mas depois de fazer o que possa ser necessário, cada 
driver chama a função que contém o laço principal co¬ 
mum, o qual é executado eternamente; não há nenhum 
retorno para o processo. Dentro do laço principal, uma 
mensagem é recebida, uma função para executar a opera¬ 
ção necessária a cada mensagem é chamada e, então, uma 
mensagem de resposta é gerada. 

0 laço principal comum chamado por cada tarefa de 
driver de disco não é apenas uma cópia de uma função de 
biblioteca compilada em cada driver. Há somente uma 
cópia do código do laço principal no código binário do MI- 
Nix. A técnica utilizada é fazer cada um dos drivers indivi¬ 
duais passar para o laço principal um parâmetro que con¬ 
siste em um ponteiro para uma tabela dos endereços das 
funções que o driver utilizará para cada operação e, então, 
chamar essas funções indiretamente. Essa técnica também 
torna possível que os drivers compartilhem funções. A Fi¬ 
gura 3-17 mostra um esboço do laço principal, de uma 
forma semelhante à da Figura 3-16. Declarações como 

code = (*entry_points->dev_read)(&mess); 

são chamadas indiretas de funções. Uma função devjread 
diferente é chamada por cada driver, mesmo que cada um 
deles esteja executando o mesmo laço principal. Mas algu¬ 
mas outras operações, por exemplo CLOSE, são suficiente¬ 
mente simples para que mais de um dispositivo possa cha¬ 
mar a mesma função. 

Essa utilização de uma única cópia do laço é uma boa 
ilustração do conceito de processo que introduzimos no 
Capítulo 1 e discutimos demoradamente no Capítulo 2. Há 
somente uma cópia do código executável na memória para 
o laço principal dos drivers de dispositivo de bloco, mas ela 
é executada como o laço principal de três ou de mais pro¬ 
cessos distintos. Cada um desses processos está provavel¬ 
mente em um ponto diferente do código em um dado ins¬ 
tante, e cada um está operando sobre seu próprio conjunto 
de dados e tem sua própria pilha. 

Há seis possíveis operações que podem ser solicitadas 
para qualquer driver de dispositivo. Essas operações corres¬ 
pondem aos possíveis valores que podem ser localizados no 
campo m.mjype da mensagem na Figura 3-15. Elas são: 

1. OPEN 

2. CLOSE 

3. READ 

4. WRITE 

5. IOCTL 

6. SCATTERED_ 10 
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message mess; /* buffer de mensagem */ 

void shared_ io_task(struct driver_ table *entry_points) { 

/* a inicialização é feita por cada tarefa antes de chamar esta */ 
while (TRUE) { 

receive(ANY, &mess); 
caller = mess.source; 
switch(mess.type) { 

case READ: rcode = (*entry_points->dev_read)(&mess); break; 

caseWRITE: rcode = (*entry_points->dev_write)(&mess);break; 

/* Outros casos entram aqui, incluindo OPEN, CLOSE e IOCTL */ 
default: rcode = ERROR; 

} 

mess.type = TASK_ REPLY; 

mess.status = rcode; /* código resultante */ 

send(caller, &mess); 

} 

} 

Figura 3-17 Um procedimento principal compartilhado de tarefa de E/S utilizando chamadas indiretas. 


A maioria dessas operações é provavelmente familiar para 
leitores com experiência em programação. No nível do dri¬ 
ver de dispositivo, a maioria das operações está relaciona¬ 
da a chamadas de sistema com o mesmo nome. Por exem¬ 
plo, os significados de READ e writk devem ser claros. Para 
cada uma dessas operações, um bloco de dados é transferi¬ 
do do dispositivo para a memória do processo que iniciou 
a chamada, ou vice-versa. Uma operação READ normal¬ 
mente não resulta em um retorno para o processo até que 
a transferência de dados esteja completa, mas um sistema 
operacional pode bufferizar dados transferidos durante um 
WRITE para transferência real para o destino em um mo¬ 
mento posterior e retornar para o processo imediatamente. 
Isso está ótimo no que diz respeito ao processo; ele, então, 
está livre para reutilizar o buffer de que o sistema operaci¬ 
onal copiou os dados para gravar. OPEN e CLOSE para um 
dispositivo têm significados semelhantes para a maneira 
como as chamadas de sistema OPEN e CLOSE aplicam-se a 
operações em arquivos: uma operação OPEN deve verificar 
se o dispositivo está acessível ou retornar uma mensagem 
de erro se não, e uma operação CLOSE deve garantir que 
quaisquer dados bufferizados que foram gravados pelo 
processo foram completamente transferidos para seu desti¬ 
no final no dispositivo. 

A operação IOCTL pode não ser tão familiar. Muitos dis¬ 
positivos de E/S têm parâmetros operacionais que ocasio¬ 
nalmente devem ser examinados e talvez alterados. As ope¬ 
rações IOCTL fazem isso. Um exemplo familiar é alterar a 
taxa de transmissão ou a paridade de uma linha de comu¬ 
nicações. Para dispositivos de bloco, as operações IOCTL são 
menos comuns. 0 exame ou a modificação do modo como 
um dispositivo de disco é particionado são feitos utilizando 
uma operação IOCTL no MiXlX (embora isso pudesse ser fei¬ 
to igualmente bem, lendo e gravando um bloco de dados). 

A operação SCATTEREDJO é, sem dúvida, a menos fa¬ 
miliar dessas operações. Exceto com dispositivos de disco 
excessivamente rápidos (p. ex., o disco de RAM), é difícil 
obter um desempenho satisfatório de E/S de disco se todas 


as solicitações de disco forem para blocos individuais, um 
por vez. Uma solicilaçÃo SCATTEREDJO permite que o sis¬ 
tema de arquivos faça uma solicitação de leitura ou grava¬ 
ção de múltiplos blocos. No caso de uma operação read, os 
blocos adicionais podem não ter sido solicitados pelo pro¬ 
cesso em cujo favor a chamada é feita; o sistema operacio¬ 
nal tenta antecipar solicitações de dados futuras. Em tal 
solicitação nem todas as transferências solicitadas são ne¬ 
cessariamente atendidas pelo driver de dispositivo. A soli¬ 
citação para cada bloco pode ser modificada por um bit de 
sinalização que informa o driver de dispositivo de que a 
solicitação é opcional. De fato, o sistema de arquivos pode 
dizer, “seria ótimo ter todos esses dados, mas, realmente, 
não preciso de todos eles agora". O dispositivo pode fazer o 
que é melhor para ele. O driver de disquete, por exemplo, 
retornará todos os blocos de dados que ele pode ler de uma 
única trilha, efetivamente dizendo: "Darei esses a você, mas 
leva muito tempo para mover para outra trilha; solicite- 
me novamente o resto mais tarde." 

Quando os dados devem ser gravados, não há nenhu¬ 
ma pergunta sobre se é opcional ou não gravar um bloco 
particular. Contudo, o sistema operacional pode bufferi¬ 
zar algumas solicitações de gravação na esperança de que 
a gravação de múltiplos blocos possa ser feita com maior 
eficiência do que tratar cada solicitação à medida que ela 
chega. Em uma solicitação SCATTEREDJO, seja para ler 
ou para gravar, a lista de blocos solicitada é classificada, e 
isso torna a operação mais eficiente do que tratar as solici¬ 
tações aleatoriamente. Ademais, fazer uma única chama¬ 
da para o driver para transferir múltiplos blocos reduz o 
número de mensagens enviadas dentro do minix. 

3.5.2 Software Comum de Driver de 
Dispositivo de Bloco 

As definições requeridas por todos os drivers de disposi¬ 
tivo de bloco estão localizadas em driver, b. A coisa mais 
importante neste arquivo é a estrutura driver, nas linhas 
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9010 a 9020, que é utilizada por cada driver para passar 
uma lista dos endereços das funções que ele utilizará para 
executar cada parte do seu trabalho. Também definida aqui 
está a estrutura device (linhas 9031 a 9034) que armazena 
as informações mais importantes sobre partições, o ende¬ 
reço de base e o tamanho, em unidades de byte. Esse for¬ 
mato foi escolhido para que nenhuma conversão fosse ne¬ 
cessária ao trabalhar com dispositivos baseados em me¬ 
mória, maximizando a velocidade de resposta. Com discos 
reais há tantos outros fatores atrasando o acesso que a con¬ 
versão para setores não é uma inconveniência significati¬ 
va. 

O laço principal e as funções compartilhadas de todas 
as tarefas de driver de bloco estão em driver. c. Depois de 
fazer qualquer inicialização específica de hardware que 
possa ser necessária, cada driver chama driver _task. pas¬ 
sando uma estrutura driver como o argumento para a cha¬ 
mada. Depois de obter o endereço de um buffer utilizado 
para operações de DMA, o laço principal (linhas 9158 a 
9199) é iniciado. Esse laço é executado eternamente; não 
há nenhum retorno para 0 processo. 

O sistema de arquivos é 0 único processo do qual se 
supõe 0 envio de uma mensagem para uma tarefa de dri¬ 
ver. O switch nas linhas 9165 a 9175 verifica isso. Uma 
interrupção de hardware remanescente é ignorada, qual¬ 
quer outra mensagem maldirecionada resulta somente na 
impressão de um aviso na tela. Isso parece bastante inó¬ 
cuo, mas naturalmente 0 processo que enviou a mensa¬ 
gem errônea está, é provável, permanentemente bloquea¬ 
do. esperando uma resposta. Em switch no laço principal, 
os primeiros três tipos de mensagem, DEVJOPEN . 
DEVJELOSE. e DEVJOCTL. resultam em chamadas indi¬ 
retas utilizando endereços passados na estrutura driver. As 
mensagens DEV_READ. ÜEV_WRITE. e SCATTERED_lO 
resultam em chamadas diretas a dojrdwt ou do_vrdui. 
Entretanto, a estrutura driver é passada como um argu¬ 
mento por todas as chamadas a partir de switch, sejam 
diretas ou indiretas, de maneira que todas as rotinas cha¬ 
madas possam utilizá-la novamente mais tarde, conforme 
necessário. 

Depois de fazer 0 que é solicitado na mensagem, al¬ 
gum tipo de limpeza pode ser necessária, dependendo da 
natureza do dispositivo. Para um disquete, por exemplo, 
isso pode envolver disparar um temporizador para desligar 
0 motor da unidade de disco se outra solicitação não che¬ 
gar logo. Uma chamada indireta também é utilizada para 
isso. Seguindo-se à limpeza, uma mensagem de resposta é 
criada e enviada ao processo (linhas 9194 a 9198). 

A primeira coisa que cada tarefa faz depois de entrar no 
laço principal é chamar init_buffer (linha 9205), que atri¬ 
bui um buffer para utilização em operações de DMA. O 
mesmo buffer é utilizado por todas as tarefas de driver, se é 
que elas 0 utilizam — alguns drivers não utilizam DMA. 
As inicializações para cada entrada depois da primeira são 
redundantes, mas não causam nenhum mal. Seria mais 
incômodo codificar um teste para ver se a inicialização deve 
ser pulada. 


O fato de essa inicialização ser desnecessária no final 
das contas deve-se a uma particularidade do hardware do 
IBM PC original, que requer que 0 buffer de DMA não ul¬ 
trapasse um limite de 64K. Isto é, um buffer de DMA de 1K 
pode começar em 64510, mas não em 64514 porque um 
buffer que inicia no último endereço simplesmente se es¬ 
tende além do limite de 64K em 65536. 

Essa regra irritante ocorre porque 0 IBM PC utilizou 
um chip de DMA antigo, 0 8237A da Intel, que contém um 
contador de 16 bits. Um contador maior é necessário por¬ 
que 0 DMA utiliza endereços absolutos, não endereços re¬ 
lativos, para um registrador de segmento. Em máquinas 
mais antigas que podem endereçar somente 1M de memó¬ 
ria, os l6 bits de ordem baixa do endereço de DMA são car¬ 
regados no 8237A e os 4 bits de ordem alta são carregados 
em um latch" de 4 bits. Máquinas mais recentes utilizam 
um latch de 8 bits e podem endereçar l6M. Quando 0 8237A 
vai de OxFFFF a 0x0000, ele não atualiza 0 latch-, então, 0 
endereço de DMA repentinamente pula 64K para baixo na 
memória. 

Um programa em C portável não pode especificar uma 
posição absoluta na memória para uma estrutura de da¬ 
dos, portanto, não há nenhuma maneira de evitar que 0 
compilador coloque 0 buffer em uma posição não-utilizá- 
vel. A solução é alocar uma matriz de bytes com 0 dobro do 
tamanho necessário em buffer (linha 9135) e reservar um 
ponteiro tmpjjuf (linha 9136) a fim de realmente aces¬ 
sar essa matriz. Init_buffer faz uma configuração experi¬ 
mental de tmp_buf‘í\>on\.wAo para 0 início de buffer; en¬ 
tão, testa para ver se isso permite espaço suficiente antes do 
limite de 64K ser alcançado. Se a configuração experimen¬ 
tal não oferecer espaço suficiente, tmpjmfé incrementa¬ 
do pelo número de bytes realmente necessários. Assim al¬ 
gum espaço sempre é desperdiçado em uma das extremi¬ 
dades do espaço atribuído a buffer, mas nunca há uma fa¬ 
lha decorrente do fato de 0 buffer cair no limite de 64K. 

Computadores mais novos da família IBM PC têm me¬ 
lhores controladoras de DMA. Esse código poderia ser sim¬ 
plificado, e uma quantidade pequena de memória poderia 
ser requerida, se fosse possível assegurar que a máquina do 
usuário é imune a esse problema. Se você estiver conside¬ 
rando isso, entretanto, considere como se manifestaria 0 
bug se você estivesse errado. Se um buffer de DMA de 1K é 
desejado, a chance é de 1 em 64 que haverá um problema 
em uma máquina com 0 chip de DMA antigo. Cada vez 
que 0 código-fonte do kernel for modificado de uma ma¬ 
neira que altera 0 tamanho do kernel compilado, há a 
mesma probabilidade de que 0 problema manifeste-se. Pro¬ 
vavelmente, quando a falha ocorrer, no mês que vem ou 
no ano que vem, ela será atribuída à última modificação 


*N. de T. Circuito ou elemento de circuito usado para manter um esta¬ 
do específico (como 011 ou off, verdadeiro lógico ou falso). 0 latch só 
muda de estado em resposta a uma entrada predeterminada. ( Dicio¬ 
nário de Informática. Microsoft Press. Rio de Janeiro, Editora Cam¬ 
pus, 1998.) 
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do código. “Recursos” inesperados de hardware como esse 
podem levar ao consumo de semanas procurando bugs ex¬ 
cessivamente obscuros (e mais ainda quando, como esse, 
o manual técnico de referência não diz nenhuma palavra 
sobre eles). 

Do_rdwt é a próxima função em driver, c. Essa, por sua 
vez, pode chamar três funções dependente de dispositivo 
apontadas pelos campos dr_ prepare, dr_schedule e 
dr Jinisb na estrutura driver. No que segue, utilizaremos 
a notação da linguagem de C *function_pointer para in¬ 
dicar que estamos discutindo sobre a função apontada por 
function _pointer. 

Depois de verificar se a contagem de byte na solicitação 
é positiva, do_rdwt chama *dr_prepare. Isso deve ser bem- 
sucedido, uma vez que *dr_prepare somente pode falhar 
se um dispositivo inválido é especificado em uma operação 
OPEN. Em seguida, uma estrutura-padrão iorequest_s (de¬ 
finida na linha 3194 em include/minlx/type.h) é preen¬ 
chida. Então, vem outra chamada indireta, desta vez para 
*dr_schedule. Como veremos na discussão de hardware de 
disco na próxima seção, responder a solicitações de disco 
na ordem em que elas são recebidas pode ser ineficiente e 
essa rotina permite que um dispositivo particular trate soli¬ 
citações da melhor maneira para o dispositivo. A indireção 
aqui mascara muitas possíveis variações na maneira como 
cada dispositivo atua. Para o disco de RAM, dr_scbedule 
aponta para uma rotina que realmente executa a E/S, e a 
próxima chamada indireta, para drJinisb, é uma opera¬ 
ção que não faz nada. Para um disco real, dr Jinisb apon¬ 
ta para uma rotina que leva a cabo todas as transferências 
de dados pendentes solicitadas em todas as chamadas ante¬ 
riores para *dr_schedule desde a última chamada a 
*dr Jinish. Como veremos, entretanto, em algumas circuns¬ 
tâncias, a chamada a *dr Jinisb pode não resultar em uma 
transferência de todos os dados solicitados. 

Em qualquer chamada que faz uma transferência de 
dados real, a contagem de iojnbytes na estrutura 
iorequest_s é modificada, retornando um número negati¬ 
vo se ocorreu um erro ou um número positivo que indica a 
diferença entre o número de bytes na solicitação original e 
o número transferido com êxito. Não é necessariamente 
um erro se nenhum byte for transferido; isso indica que o 
fim do dispositivo foi alcançado. Ao voltar para o laço prin¬ 
cipal, o código de erro negativo é retornado no campo 
REPJTATUS da mensagem de resposta se ocorreu um erro. 
Caso contrário, os bytes que restam ser transferidos são sub¬ 
traídos da solicitação original no campo COUNT da men¬ 
sagem (linha 9249) e 0 resultado (0 número realmente 
transferido) é retornado no campo REPJTATUS da men¬ 
sagem de resposta de driver Jask. 

A próxima função, do_vrdwt, manipula toda solicita¬ 
ção de E/S dispersa ( scattered). Uma mensagem que re¬ 
quisita uma solicitação de E/S dispersa utiliza 0 campo 
ADDRESS para apontar para uma matriz de estruturas do 
tipo iorequest_s, cada uma especificando as informações 
necessárias para uma solicitação: 0 endereço do buffer, 0 
deslocamento ( offset) no dispositivo, 0 número de bytes e 


se a operação é uma leitura ou uma gravação. Todas as 
operações em uma solicitação serão para leitura ou para 
gravação e elas serão classificadas na ordem de blocos no 
dispositivo. Há mais trabalho a fazer do que a simples lei¬ 
tura ou a gravação realizada por dojdwt, uma vez que a 
matriz de solicitações deve ser copiada para 0 espaço do 
kernel , mas uma vez que isso foi feito, as mesmas três cha¬ 
madas indiretas para as rotinas dependentes de dispositivo 
*drjrepare, *dr_schedulee *dr Jinisb são feitas. A dife¬ 
rença é que a chamada do meio, *dr_scbedule, é feita em 
um laço, uma vez para cada solicitação, ou até que um 
erro ocorra (linhas 9288 a 9290). Depois de terminar 0 laço, 
*dr Jinisb é chamada uma vez e, então, a matriz de solici¬ 
tações é copiada de volta para 0 lugar de onde veio. 0 cam¬ 
po iojnbytes de cada elemento na matriz terá sido altera¬ 
do para refletir 0 número de bytes transferido e embora 0 
total não seja copiado diretamente na mensagem de res¬ 
posta que driver Jask cria, 0 processo pode extrair 0 total 
dessa matriz. 

Em uma solicitação de leitura de E/S dispersa, nem to¬ 
das as transferências solicitadas na chamada a dr_schedule 
são necessariamente atendidas quando a chamada final a 
*dr Jinisb é feita, como discutimos na seção anterior. 0 
campo iojrequest na estrutura iorequest_s contém um bit 
de sinalização que informa ao driver de dispositivo se uma 
solicitação para esse bloco é opcional. 

As próximas poucas rotinas em driver, c são para supor¬ 
te geral das operações acima. Uma chamada *dr_name 
pode ser utilizada para retornar 0 nome de um dispositivo. 
Para um dispositivo sem nenhum nome específico, a fun¬ 
ção no_names recupera 0 nome do dispositivo a partir da 
tabela de tarefas. Alguns dispositivos podem não requerer 
um serviço em particular, por exemplo, um disco de RAM 
não requer que qualquer coisa especial seja feita com uma 
solicitação DEVjOLOSE. A função dojnop cumpre esse 
papel aqui, retornando vários códigos que dependem do 
tipo de solicitação. As funções seguintes, nop Jinisb e 
nop_cleanup, são rotinas igualmente inócuas para dispo¬ 
sitivos que não precisam dos serviços de *dr Jinisb ou 
*dr_cleanup. 

Algumas funções de dispositivo de disco requerem um 
retardamento, por exemplo, para esperar 0 motor de uma 
unidade de disquetes começar a funcionar. Assim driver.c 
é um bom lugar para a próxima função, dock_mess, utili¬ 
zada para enviar mensagens à tarefa de relógio. Ela é cha¬ 
mada com 0 número de tiques de relógio a esperar e 0 en¬ 
dereço de uma função a chamar quando 0 limite de tempo 
for atingido. 

Por fim, dojiiocntl (linha 9364) leva a cabo solicita¬ 
ções DEV_I0CTL para um dispositivo de bloco. É um erro se 
qualquer operação DEVJOCTL que não ler (DIOGETP) ou 
gravar (DIOSETP) as informações de partição for solicita¬ 
da. Dojiiocntl chama a função *dr Jrepare do dispositi¬ 
vo para verificar se 0 mesmo é válido e obter um ponteiro 
para a estrutura de dispositivo que descreve a base e 0 ta¬ 
manho da partição em unidades de byte. Em uma solicita¬ 
ção de leitura, ela chama a função *dr_geometry do dis- 
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positivo para obter as últimas informações sobre a parti¬ 
ção referentes a cilindros, a cabeçotes e a setores. 

3.5.3 A Biblioteca de Driver 

Os arquivos drvlib.b e drvlib.e contêm o código depen¬ 
dente de sistema que suporta partições de discos em com¬ 
putadores compatíveis com IBM PC. 

0 particionamento permite que um único dispositivo 
de armazenamento seja dividido em subdispositivos. Ele é 
mais comumente utilizado com discos rígidos, mas o mi- 
NTX também oferece suporte para particionar disquetes. Al¬ 
gumas razões para particionar um dispositivo de disco são: 

1. A capacidade de disco é mais barata por unidade 
em discos grandes. Se dois ou mais sistemas ope¬ 
racionais com sistemas de arquivo diferentes são 
utilizados, é mais econômico particionar um úni¬ 
co disco grande do que instalar múltiplos discos 
menores para cada sistema operacional. 

2. Os sistemas operacionais podem ter limites para o 
tamanho de dispositivo que podem gerenciar. A 
versão do mintx discutida aqui pode gerenciar um 
sistema de arquivos de 1 GB, mas versões mais an¬ 
tigas estão limitadas a 256MB. Qualquer espaço 
em disco além disso será desperdiçado. 

3. Dois ou mais sistemas diferentes de arquivo podem 
ser utilizados por um sistema operacional. Por 
exemplo, um sistema de arquivos padrão pode ser 
utilizado para arquivos normais e um sistema de 
arquivos diferentemente estruturado pode ser uti¬ 
lizado para espaço de troca de memória virtual. 

4. Pode ser conveniente pôr uma parte dos arquivos 
de um sistema em um dispositivo lógico separado. 
A colocação do sistema de arquivos raiz do MINIX 
em um dispositivo pequeno torna fácil fazer ba- 
ckup e facilita copiar ele para um disco de RAM 
em tempo de inicialização. 

0 suporte para partições de disco é específico da plata¬ 
forma. Essa especificidade não está relacionada com o har¬ 
dware. 0 suporte de partição é independente de dispositivo. 
Mas se mais de um sistema operacional rodará em um con¬ 
junto particular de hardware, todos devem concordar quan¬ 
to ao formato para a tabela de partição. Em IBM PCs o 
padrão é dado pelo cornando fdisk do MS-DOS, e outros sis¬ 
temas operacionais, como minlx, OS/2 e Linux, utilizam esse 
formato para que eles possam coexistir com o MS-DOS. 
Quando o MINIX é portado para outro tipo de máquina, faz 
sentido utilizar um formato de tabela de partição compatí¬ 
vel com outros sistemas operacionais utilizados no novo 
hardware. Portanto, o código-fonte do mintx para suportar 
partições em computadores IBM é configurado em drvlib.e, 
em vez de ser incluído em drivers, para tornar mais fácil 
portar o MINIX para um hardware diferente. 

A estrutura de dados básica herdada dos projetistas de 
firmware é definida em include/ibm/partition.b, o qual é 
incluído por uma declaração #include em drvlib.b. Isso 


inclui as informações sobre a geometria cilindro—cabeço¬ 
te-setor de cada partição, assim como os códigos para iden¬ 
tificar 0 tipo de sistema de arquivos na partição e ativar 
um sinalizador que indica se é inicializável. A maioria des¬ 
sas informações não é requerida pelo mintx, uma vez que o 
sistema de arquivos tenha sido verificado. 

A função partition (em drvlib.e, A linha 9521) é cha¬ 
mada quando um dispositivo de bloco é aberto pela pri¬ 
meira vez. Seus argumentos incluem uma estrutura dri¬ 
ver, para que ela possa chamar funções específicas de dis¬ 
positivo, um número inicial de dispositivo secundário e um 
parâmetro que indica se o estilo de particionamento é dis¬ 
quete, partição primária ou subpartição. Ela chama a fun¬ 
ção específica de dispositivo *dr_prepare para verificar se 
o dispositivo é válido e para obter o endereço base e o ta¬ 
manho em uma estrutura device do tipo mencionado na 
seção anterior. Então, ela chama get _partjable que de¬ 
termina se uma tabela de partição está presente e, se esti¬ 
ver. a lê. Se não houver nenhuma tabela de partição, o tra¬ 
balho estará completo. Caso contrário, o número do dispo¬ 
sitivo secundário da primeira partição é calculado, utili¬ 
zando as regras para numeração de dispositivos secundá¬ 
rios que se aplicam ao estilo de particionamento especifi¬ 
cado na chamada original. No caso de partições primárias, 
a tabela de partição é classificada de tal modo que a ordem 
das partições de arquivo é consistente com a utilizada por 
outros sistemas operacionais. 

Nesse ponto, outra chamada é feita para *dr_prepare, 
desta vez utilizando o recém-calculado número de disposi¬ 
tivo da primeira partição. Se o subdispositivo é válido, en¬ 
tão, um laço é feito sobre todas as entradas na tabela, veri¬ 
ficando se os valores lidos da tabela no dispositivo não estão 
fora do intervalo obtido anteriormente para a base e para o 
tamanho do dispositivo inteiro. Se houver uma discrepân¬ 
cia, a tabela na memória é ajustada para adaptar-se. Isso 
pode parecer paranóico, mas como as tabelas de partição 
podem ser gravadas por sistemas operacionais diferentes, 
um programador utilizando outro sistema poderia malici¬ 
osamente tentar utilizar a tabela de partição para algo ines¬ 
perado ou poderia haver lixo na tabela em disco por algu¬ 
ma outra razão. Confiamos mais nos números que calcu¬ 
lamos utilizando o mintx. Melhor seguro que arrependido. 

Ainda dentro do laço. para todas as partições no dispo¬ 
sitivo, se a partição for identificada como uma partição 
mintx, j Oartítion será recursivamente chamada para reunir 
as informações de subpartição. Se uma partição for identi¬ 
ficada como uma partição estendida, a próxima função no 
arquivo, extpartition, será chamada em seu lugar. 

Extpartition (linha 9593) realmente não tem nada a 
ver com o sistema operacional MINIX, portanto, não discu¬ 
tiremos seus detalhes. 0 MS-DOS utiliza partições estendi¬ 
das, que são simplesmente outro mecanismo para criar 
subpartições. Para suportar comandos MINTX que podem 
ler e gravar arquivos MS-DOS, precisamos conhecer essas 
subpartições. 

Get_part_table (linha 9642) chama dojrdwt para 
obter o setor em um dispositivo (ou subdispositivo) onde 
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uma tabela de partição está localizada. 0 argumento de 
deslocamento ( offset ) é zero se ela foi chamada para obter 
uma partição primária ou não-zero para uma subparti- 
ção. Ela verifica o número mágico (OxAA55) e retorna o 
status true ou false para indicar se uma tabela de partição 
válida foi localizada. Se uma tabela for localizada, ela a 
copia para o endereço de tabela que foi passado como um 
argumento. 

Por fim, sort (linha 9676 ) classifica as entradas em uma 
tabela de partição pelo setor mais baixo. As entradas que 
são marcadas como não tendo nenhuma partição são ex¬ 
cluídas da classificação, por isso aparecem no final, mes¬ 
mo que possa ter um valor zero em seu campo de setor 
baixo. Essa classificação é um simples bublesorf\ não há 
nenhuma necessidade de utilizar um algoritmo extrava¬ 
gante para classificar uma lista de quatro itens. 

3.6 DISCOS DE RAM 

Agora veremos os drivers individuais de dispositivo de 
bloco e estudaremos vários deles detalhadamente. 0 pri¬ 
meiro que veremos é o drii : er de disco de RAM. Ele pode ser 
utilizado para oferecer acesso a qualquer parte da memó¬ 
ria. Sua utilização principal é permitir que uma parte da 
memória seja reservada para utilização como um disco co¬ 
mum. Isso não oferece armazenamento permanente, mas 
uma vez que os arquivos tenham sido copiados para essa 
área, eles podem ser acessados com extrema rapidez. 

Em um sistema como o MINIX, que foi projetado para 
trabalhar até em computadores com somente um disque¬ 
te, o disco de RAM tem outra vantagem. Colocando o dis¬ 
positivo raiz no disco de RAM, o disquete pode ser montado 
e desmontado à vontade, o que permite uma mídia remo¬ 
vível. Se o dispositivo raiz fosse colocado no disquete, seria 
impossível salvar arquivos em disquetes, uma vez que o 
dispositivo raiz (o único disquete) não pode ser desmonta¬ 
do. Além disso, ter o dispositivo raiz no disco de RAM torna 
o sistema altamente flexível: qualquer combinação de dis¬ 
quetes ou de discos rígidos pode ser montada nele. Embora 
a maioria dos computadores de hoje em dia tenha discos 
rígidos, exceto os computadores utilizados em sistemas em¬ 
butidos, o disco de RAM é útil durante a instalação, antes 
de o disco rígido estar pronto para utilização pelo MINIX, 


‘N. de T. Um algoritmo de pesquisa que se inicia no final de uma lista 
com n elementos e vai subindo aos poucos, testando o valor de cada par 
adjacente de elementos e trocando-os de posição, caso não estejam na 
ordem certa. O processo é repetido para os n -1 elementos restantes até 
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lor posicionado no final da fila. 0 termo "classificação de bolhas” (bub- 
ble sort) origina-se do fato de que os elementos "mais leves" da lista 
(os menores elementos) vão subindo, como bolhas, até a superfície. 
Também chamado de excbange sort (classificação por troca). ( Dicio¬ 
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pus, 1998.) 


ou quando se quer utilizar o MINIX temporariamente sem 
fazer uma instalação completa. 

3.6.1 Hardware e Software do Disco 
de RAM 

A idéia por trás de um disco de RAM é simples. Um dis¬ 
positivo de bloco é uma mídia de armazenamento com dois 
comandos: gravar um bloco e ler um bloco. Normalmente 
esses blocos são armazenados em memórias rotativas, como 
disquetes ou discos rígidos. Um disco de RAM é mais sim¬ 
ples. Ele simplesmente utiliza uma porção pré-alocada da 
memória principal para armazenar os blocos. Um disco de 
RAM tem a vantagem de ter acesso instantâneo (nenhum 
retardo rotacional ou de busca), tornando-o conveniente 
para armazenar programas ou dados que são acessados com 
freqüência. 

A propósito, vale a pena indicar brevemente uma dife¬ 
rença entre sistemas que suportam sistemas montados de 
arquivos e aqueles que não suportam (p. ex., o MS-DOS e o 
WINDOWS). Com sistemas montados de arquivos, o disposi¬ 
tivo raiz está sempre presente em uma posição fixa. e os 
sistemas de arquivos removíveis (i. e., discos) podem ser 
montados na árvore de arquivos para formar um sistema 
de arquivos integrado. Uma vez que tudo tenha sido mon¬ 
tado, o usuário não precisa preocupar-se com saber em que 
dispositivo estão os arquivos. 

Em contraposição, em sistemas tipo MS-DOS, o usuário 
deve especificar a posição de cada arquivo, seja explicita¬ 
mente como em B:\DIR\FILE ou utilizando certos padrões 
(dispositivo atual, diretório atual, etc.). Com somente um 
ou dois disquetes, esse peso é gerenciável, mas, em um sis¬ 
tema de computador de grande porte, com dúzias de dis¬ 
cos, precisar acompanhar dispositivos o tempo todo seria 
insuportável. Lembre-se de que o UNIX roda em sistemas 
que vão desde um IBM PC, passando por estações de traba¬ 
lho e por supercomputadores até o Cray-2; o MS-DOS exe¬ 
cuta somente em sistemas pequenos. 

A Figura 3-18 mostra a idéia por trás de um disco de 
RAM. 0 disco de RAM é dividido em n blocos, dependendo 
de quanta memória foi atribuída a ele. Cada bloco tem o 
mesmo tamanho que o tamanho de bloco utilizado em dis¬ 
cos reais. Quando o driver recebe uma mensagem para ler 
ou para gravar um bloco, ele simplesmente calcula onde, 
na memória de disco de RAM os blocos solicitados estão e 
lê-os ou grava neles, em vez de ou em um disquete ou dis¬ 
co rígido. A transferência é feita chamando um procedi¬ 
mento de linguagem assembly que copia para o programa 
de usuário na velocidade máxima de que o hardware é ca¬ 
paz. 

Um driver de disco de RAM pode suportar várias áreas 
da memória utilizadas como disco de RAM, cada uma dis¬ 
tinguida por um número diferente de dispositivo secundá¬ 
rio. Normalmente essas áreas são distintas, mas em algu¬ 
mas situações pode ser conveniente tê-las sobrepondo-se, 
como veremos na próxima seção. 
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3.6.2. Visão Geral do Driver de Disco 
de RAM no MINIX 

0 driver de disco de RAM é na realidade quatro drivers 
intimamente relacionados em um. Cada mensagem para 
ele especifica um dispositivo secundário como segue: 

0:/dev/ram l:/dev/mem 2:/dev/kmem 
3: /dev/null 

0 primeiro arquivo especial listado acima, /dev/ram, é 
um verdadeiro disco de RAM. Nem seu tamanho nem sua 
origem são definidos no driver. Eles são determinados pelo 
sistema de arquivos quando MINIX é inicializado. Por pa¬ 
drão, um disco de RAM do mesmo tamanho que o disposi¬ 
tivo de imagem do sistema de arquivos raiz é criado; então, 
o sistema de arquivos raiz pode ser copiado para ele. Um 
parâmetro de inicialização pode ser utilizado para especi¬ 
ficar um disco de RAM maior que o sistema de arquivos 
raiz; ou, se a raiz não será copiada para a RAM, o tamanho 
especificado pode ser qualquer valor que se ajuste na me¬ 
mória e deixe memória suficiente para operação de siste¬ 
ma. Uma vez que o tamanho é conhecido, um bloco de 
memória suficientemente grande é localizado e removido 
do conjunto da memória, antes mesmo de o gerenciador 
de memória começar seu trabalho. Essa estratégia permite 
aumentar ou reduzir a quantidade de disco de RAM pre¬ 
sente sem recompilar o sistema operacional. 

Os dois próximos dispositivos secundários são utiliza¬ 
dos para ler e para gravar memória física e memória do 
kernel , respectivamente. Quando /dev/mem é aberto e lido, 
ele fornece o conteúdo de posições físicas da memória ini¬ 
ciando no endereço absoluto zero (os vetores de interrup¬ 
ções de modo real). Programas normais de usuário nunca 
fazem isso, mas um programa de sistema preocupado com 
depurar o sistema talvez necessite dessa facilidade. A ope¬ 
ração de abrir /dev/mem e gravar nele mudará os vetores 
de interrupção. É desnecessário dizer, isso somente deve ser 
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feito com a maior cautela por um usuário experimentado 
que saiba exatamente o que está fazendo. 

O arquivo especial /dev/kmem é como /dev/mem. ex¬ 
ceto que o byte 0 desse arquivo é o byte 0 da memória de 
dados do kernel , uma posição cujo endereço absoluto va¬ 
ria, dependendo do tamanho do código do kernel do MI- 
NIX. Ele também é utilizado principalmente para depura¬ 
ção e programas muito especiais. Note que as áreas de dis¬ 
co de RAM cobertas por esses dois dispositivos secundários 
sobrepõem-se. Se você souber exatamente como o kernel 
está colocado na memória, você pode abrir /dev/mem. 
procurar o começo da área de dados do kernel e ver exata¬ 
mente a mesma coisa que é lida desde o início de /dei/ 
k/nem. Mas, se recompilar o kernel. alterar seu tamanho 
ou se em uma versão subsequente do MIMX o kernel for 
movido para outro lugar na memória, você precisará pro¬ 
curar uma quantidade diferente em /dev/mem para ver a 
mesma coisa que você vê no início de /dev/kmem. Ambos 
esses arquivos especiais deverão ser protegidos de modo que 
ninguém, exceto o superusuário, possa utilizá-los. 

O último arquivo nesse grupo ./dev/null, é um arquivo 
especial que recebe dados e joga-os fora. Ele é comumente 
utilizado em comandos de shell quando o programa que 
está sendo chamado gera saída que não é necessária. Por 
exemplo, 

a.out >/dev/null 

executa o programa a.out mas descarta sua saída. O dri¬ 
ver de disco de RAM efetivamente trata esse dispositivo se¬ 
cundário como se ele tivesse tamanho zero, assim nenhum 
dado jamais é copiado para ele ou a partir dele. 

O código para tratar /dev/ram, / dev/mem e/dev/kmem 
é idêntico. A única diferença entre eles é que cada um cor¬ 
responde a uma porção diferente de memória, indicada 
pelas matrizes ram_origin e ramjimit, cada uma inde¬ 
xada pelo número de dispositivo secundário. 
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3-6.3 Implementação do Driver de 
Disco de RAM no MINIX 

Como com outros drivers de disco, 0 laço principal do 
disco de RAM está no arquivo driver.c. 0 suporte específico 
de dispositivo para dispositivos de memória está em 
memory.c. A matriz m_geom (linha 9721) guarda a base 
e 0 tamanho de cada um dos quatro dispositivos de memó¬ 
ria. A estrutura m_dtab de driver nas linhas 9733 a 9743 
define as chamadas de dispositivo de memória que serão 
feitas a partir do laço principal. Quatro das entradas nessa 
tabela são rotinas que pouco ou nada fazem em driver.c, 
um indício seguro de que a operação de um disco de RAM 
não é terrivelmente complicada. 0 procedimento principal 
memjask (linha 9749) chama uma função para fazer 
alguma inicialização local. Depois disso, ela chama 0 laço 
principal, que recebe mensagens, despacha para 0 proce¬ 
dimento apropriado e envia as respostas. Não há nenhum 
retorno para memjask na conclusão. 

Em uma operação de leitura ou de gravação 0 laço prin¬ 
cipal faz três chamadas: uma para preparar 0 dispositivo, 
uma para agendar as operações de E/S e uma para termi¬ 
nar a operação. Para um dispositivo de memória uma cha¬ 
mada para m Jrepare é a primeira dessas. Ela verifica se 
um dispositivo secundário válido foi solicitado e, então, re¬ 
torna 0 endereço da estrutura que armazena 0 endereço de 
base e 0 tamanho da área de RAM solicitada. A segunda 
chamada é para m_schedule (linha 9774). Essa faz todo 0 
trabalho. Para dispositivos de memória, 0 nome dessa fun¬ 
ção é equivocado: por definição, qualquer posição é tão 
acessível quanto qualquer outra na memória de acesso ale¬ 
atório e, assim, não há nenhuma necessidade de fazer qual¬ 
quer agendamento, como há no caso de um disco que tem 
um braço móvel. 

A operação do disco de RAM é tão simples e rápida que 
nunca há qualquer razão para adiar uma solicitação, e a 
primeira coisa feita por essa função é limpar 0 bit que pode 
ser ativado por uma chamada de E/S dispersa para indicar 
que conclusão de uma operação é opcional. 0 endereço de 
destino passado na mensagem aponta para uma posição 
no espaço de memória do processo, e 0 código nas linhas 
9792 a 9794 converte isso em um endereço absoluto na 
memória de sistema e, então, verifica se é um endereço 
válido. A transferência de fato dos dados acontece na linha 
9818 ou na linha 9820 e é uma simples operação de cópia 
dos dados de um lugar para outro. 

Um dispositivo de memória não precisa de um terceiro 
passo para finalizar uma operação de leitura ou de grava¬ 
ção, e a entrada correspondente em mjitab é uma cha¬ 
mada para nop _fmish. 

A abertura de um dispositivo de memória é feita por 
m_do_open (linha 9829). 0 trabalho principal é feito cha¬ 
mando m Jrepare para verificar se um dispositivo válido 
está sendo referenciado. No caso de uma referência z/deiZ 
mem ou /dev/kmem, uma chamada a enable.iop (no ar¬ 
quivo protect.c ) é feita para mudar 0 nível atual de privi¬ 


légio da CPU. Isso não é necessário para acessar memória. 
É um truque para lidar com outro problema. Lembre-se de 
que a classe de CPUs Pentium implementa quatro níveis 
de privilégio. Os programas de usuário estão no nível me¬ 
nos privilegiado. Os processadores da Intel também têm 
um recurso arquitetônico que não está presente em muitos 
outros sistemas: um conjunto separado de instruções para 
endereçar portas de E/S. Nesses processadores as portas de 
E/S são tratadas separadamente da memória. Normalmen¬ 
te, uma tentativa por parte de um processo de usuário de 
executar uma instrução que endereça uma porta de E/S 
causa uma falha geral de proteção. Entretanto, há razões 
válidas para 0 minix pennitir que os usuários escrevam pro¬ 
gramas que possam acessar portas, especialmente em sis¬ 
temas pequenos. Assim enablejop muda os bits de nível 
de proteção de E/S (I/O Protection Levei — IOPI.) da CPU 
para permitir isso. 0 efeito é dar a um processo que tem 
permissão para abrir /dev/mem ou / dev/kmem 0 privilé¬ 
gio adicional de acessar portas de E/S. Em uma arquitetu¬ 
ra em que os dispositivos de E/S são endereçados como po¬ 
sições da memória, os bits rxw para esses dispositivos auto¬ 
maticamente cobrem 0 acesso para E/S. Se esse recurso fosse 
oculto, talvez fosse considerado uma falha de segurança, 
mas agora você sabe disso. Se planeja utilizar 0 minix para 
controlar 0 sistema de segurança de um banco, talvez você 
queira recompilar 0 kernel sem essa função. 

A próxima função, mjnit (linha 9849) é chamada 
somente uma vez, quando memjask é chamada pela pri¬ 
meira vez. Ela define 0 endereço de base e 0 tamanho de/ 
dev/kmem e também define 0 tamanho Ae/dev/mem como 
1MB, lóMB ou 4 GB-1, dependendo se 0 minix está sendo 
executado no modo 8088, 80286 ou 80386. Esses são os 
tamanhos máximos suportados pelo minix e não tem nada 
a ver com a quantidade de RAM instalada na máquina. 

O disco de RAM suporta várias operações IOCTL em 
mjoctl (linha 9874). MIOCRAMS1ZE é uma maneira con¬ 
veniente de 0 sistema de arquivos configurar 0 tamanho 
do disco de RAM. A operação MIOCSPSINFO é utilizada tan¬ 
to pelo sistema de arquivos como pelo gerenciador de me¬ 
mória para configurar os endereços de suas partes da tabe¬ 
la de processos na tabela psinfo, onde 0 programa utilitá¬ 
rio ps pode recuperá-los utilizando uma operação MIOCGP- 
SINFO. Ps é um programa UNIX padrão cuja implementa¬ 
ção é complicada pela estrutura de microkemel do MINIX, 
que coloca as informações da tabela de processos requeri¬ 
das pelo programa em vários lugares diferentes. A chama¬ 
da de sistema IOCTL é uma maneira conveniente de tratar 
esse problema. Caso contrário, uma nova versão deps teria 
de ser compilada cada vez que uma nova versão do MINIX 
fosse compilada. 

A última função em memory.c. é mjeometry (linha 
9934). Os dispositivos de memória não têm uma geome¬ 
tria de cilindros, trilhas e setores por trilha como unidades 
de disco mecânicas, mas no caso de 0 disco de RAM ser 
solicitado, ele atenderá fingindo ter. 
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3.7 DISCOS 

0 disco de RAM é uma boa apresentação para drivers 
de disco (porque é bem simples), mas os discos reais apre¬ 
sentam diversas questões que ainda não abordamos. Nas 
próximas seções primeiro diremos algumas palavras sobre 
hardware de disco e, então, daremos uma olhada em dri¬ 
vers de disco em geral, e o driver de disco rígido do MiNix 
em particular. Não examinaremos o driver de disquete de¬ 
talhadamente, mas repassaremos alguns dos pontos em que 
um driver de disquete difere de um driver de disco rígido. 

3-7.1 Hardware de Disco 

Todos os discos reais são organizados em cilindros, cada 
um contendo um número de trilhas igual ao número de 
cabeçotes empilhados verticalmente. As trilhas são dividi¬ 
das em setores, e o número de setores ao redor da circunfe¬ 
rência é geralmente de 8 a 32 em disquetes e até várias 
centenas em alguns discos rígidos. Os projetos mais sim¬ 
ples têm o mesmo número de setores em cada trilha. Todos 
os setores contêm o mesmo número de bytes, embora basta 
pensar um pouco para perceber que os setores perto da bor¬ 
da exterior do disco serão fisicamente mais longos que aque¬ 
les perto do eixo. Mas o tempo de leitura ou de gravação de 
cada setor é o mesmo. A densidade de dados é obviamente 
mais alta nos cilindros mais internos, e alguns projetos de 
disco requerem uma mudança na corrente da unidade para 
os cabeçotes de leitura-gravação para as trilhas interiores. 
Isso é tratado pelo hardware da controladora de disco e não 
é visível para o usuário (nem pelo implementador de um 
sistema operacional). 

A diferença na densidade de dados entre trilhas exterio¬ 
res e interiores significa um sacrifício em termos de capa¬ 
cidade, e existem sistemas mais sofisticados. Foram feitas 
experiências com projetos de disquete que giram em velo¬ 
cidades mais altas quando os cabeçotes estão sobre as tri¬ 
lhas exteriores, o que permite mais setores nessas trilhas, 
aumentando a capacidade do disco. Entretanto, esse tipo 
de disco não é suportado por nenhum sistema para o qual 
MIMX está disponível atualmente. Os modernos discos rígi¬ 
dos disponíveis atualmente também têm mais setores por 
trilha em trilhas exteriores que em trilhas interiores. Esses 
discos são as unidades IDE (IntegratedDevice Electro¬ 
nics) e o processamento sofisticado feito pela eletrônica 
integrada na unidade oculta os detalhes. Para o sistema 
operacional, eles parecem ter uma geometria simples com 
o mesmo número de setores em cada trilha. 

A eletrônica da unidade e da controladora é tão impor¬ 
tante quanto o hardware mecânico. 0 elemento principal 
da placa controladora que é conectado no backplane * do 
computador é um circuito integrado especializado, real- 


'N. de T. Uma placa ou estrutura de circuitos que suporta outras placas 
de circuitos, de dispositivos e as interconexões entre os dispositivos e for¬ 
nece força e sinais de dados aos dispositivos suportados. (Dicionário de 
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mente um pequeno microcomputador. Para um disco rígi¬ 
do, os circuitos da placa controladora podem ser mais sim¬ 
ples que um disquete, mas isso é porque o próprio disco 
rígido tem uma poderosa controladora eletrônica interna. 
Um recurso de dispositivo que tem implicações importan¬ 
tes para o driver de disco é a possibilidade de a controlado¬ 
ra fazer busca em duas ou mais unidades ao mesmo tem¬ 
po. Isso é conhecido como busca sobreposta ( overlapped 
seeks). Enquanto a controladora e o software estão espe¬ 
rando uma busca ser completada em uma unidade, a con¬ 
troladora pode iniciar uma busca em outra unidade. Mui¬ 
tas controladoras também podem ler ou gravar em uma 
unidade enquanto buscam em uma ou mais outras unida¬ 
des, mas uma controladora de disquete não pode ler ou 
gravar em duas unidades ao mesmo tempo. (Leitura ou 
gravação requerem que a controladora mova bits em uma 
escala de tempo de microssegundos, então, uma transfe¬ 
rência consome a maior parte do seu poder de computa¬ 
ção.) A situação é diferente para discos rígidos com contro¬ 
ladoras integradas, e em um sistema com mais de um des¬ 
ses discos rígidos eles podem operar simultaneamente, pelo 
menos no que tange à transferência entre o disco e a me¬ 
mória de buffer da controladora. Entretanto, é possível so¬ 
mente uma transferência por vez entre a controladora e a 
memória do sistema. A capacidade de executar duas ou mais 
operações ao mesmo tempo pode reduzir o tempo de aces¬ 
so médio consideravelmente. 

A Figura 3-19 compara parâmetros de disquetes de du¬ 
pla densidade e de duas faces, a mídia de armazenamento 
padrão para o IBM PC original, com parâmetros de um 
típico disco rígido de média capacidade, como os que po¬ 
dem ser encontrados em um computador baseado em Pen¬ 
tium. 0 MIN IX utiliza blocos de 1K, assim com qualquer 
um desses formatos de disco os blocos utilizados pelo sof¬ 
tware consistem em dois setores consecutivos, que sempre 
são lidos ou gravados juntos como uma unidade. 

Algo de que se deve estar ciente ao analisar as especifi¬ 
cações dos discos rígidos modernos é que a geometria espe¬ 
cificada e utilizada pelo software de driver, pode ser dife¬ 
rente do formato físico. O disco rígido descrito na Figura 3- 
19 , por exemplo, é especificado com “parâmetros recomen¬ 
dados de configuração” de 1048 cilindros, 16 cabeçotes e 
63 setores por trilha. A eletrônica da controladora monta¬ 
da no disco converte os parâmetros lógicos de cabeçote e de 
setor fornecidos pelo sistema operacional nos correspon¬ 
dentes físicos utilizados pelo disco. Esse é outro exemplo de 
um projeto comprometido em manter a compatibilidade 
com sistemas mais antigos, nesse caso firmware antigo. 
Os projetistas do IBM PC original reservaram somente um 
campo de 6 bits para a contagem de setores da ROM BIOS e 
um disco que tenha mais de 63 setores físicos por trilha 
deve trabalhar com um conjunto artificial de parâmetros 
lógicos de discos. Nesse caso, as especificações do fabrican¬ 
te afirmam que há realmente quatro cabeçotes e assim 
pareceria que há realmente 252 setores por trilha, como 
indicado na figura. Isso é uma supersimplificação, porque 
discos como esses têm mais setores nas trilhas mais exter- 
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nas do que nas trilhas internas. O disco descrito na figura 
tem quatro cabeçotes físicos, mas na realidade há ligeira¬ 
mente mais de 3 000 cilindros. Os cilindros são agrupados 
em uma dúzia de zomts que têm 57 setores por trilha nas 
zonas mais internas e até 105 cilindros por trilha nos cilin¬ 
dros mais externos. Esses números não serão encontrados 
nas especificações do disco, e as traduções feitas pela ele¬ 
trônica da unidade tornam desnecessário para nós conhe¬ 
cer esses detalhes. 

3.7.2 Software de Disco 

Nesta seção, veremos algumas questões relacionadas a 
drivers de disco em geral. Primeiro, considere quanto tem¬ 
po leva para ler ou para gravar um bloco de disco. O tempo 
necessário é determinado por três fatores: 

1. O tempo de busca (o tempo de mover o braço para 
o cilindro adequado). 

2. O retardo rotacional (o tempo para o setor ade¬ 
quado girar sob o cabeçote). 

3. Tempo real de transferência de dados. 

Para a maioria dos discos, o tempo de busca domina os 
outros dois tempos, portanto, reduzir tempo de busca 
médio significa melhorar o desempenho do sistema subs¬ 
tancialmente. 

Os dispositivos de disco são propensos a erros. Algum 
tipo de verificação de erros, uma soma de verificação ou 
uma verificação de redundância cíclica, sempre é gravado 
junto com os dados em cada setor em um disco. Mesmo os 
endereços de setores gravados quando o disco é formatado 
têm dados de verificação. O hardware da controladora de 
disquete pode informar quando um erro é detectado, mas 
o software, então, deve decidir o que fazer com ele. As con¬ 


troladoras de disco rígido freqüentemente arcam com a 
maior parte desse peso. 

Particularmente com discos rígidos, o tempo de trans¬ 
ferência para setores consecutivos dentro de uma trilha pode 
ser muito rápido. Assim, ler mais dados do que é solicitado 
e fazer cache deles na memória pode ser muito eficiente 
para acelerar o acesso de disco. 

Algoritmos de Agendamento do Braço de 
Disco 

Se o driver de disco aceita uma solicitação por vez e 
executa-as nessa ordem, isto é, primeiro a entrar, primeiro 
a ser servido ( First-Come, First-Served — FCFS), pouco 
pode ser feito para otimizar o tempo de busca. Entretanto, 
outra estratégia é possível quando o disco é muito carrega¬ 
do. É possível que enquanto o braço esteja fazendo uma 
busca em favor de uma solicitação, outras solicitações de 
disco possam ser geradas por outros processos. Muitos dri¬ 
vers de disco mantêm uma tabela, indexada por número 
de cilindro, com todas as solicitações pendentes para cada 
cilindro encadeadas juntas em uma lista encadeada enca¬ 
beçada pelas entradas da tabela. 

Dado esse tipo de estrutura de dados, podemos melho¬ 
rar o algoritmo de agendamento primeiro a entrar, primeiro 
a ser servido. Para ver como, considere um disco com 40 
cilindros. Chega uma solicitação para ler um bloco no ci¬ 
lindro 11. Enquanto a busca do cilindro 11 está em pro¬ 
gresso, chega uma nova solicitação para os cilindros 1, 36, 
16, 34, 9 e 12, nessa ordem. Eles são inseridos na tabela de 
solicitações pendentes, com uma lista encadeada separada 
para cada cilindro. As solicitações são mostradas na Figura 
3-20. 


Parâmetro 

Disquete IBM de 360KB 

Disco rígido WD de 540MB 

Número de cilindros 

40 

1048 

Trilhas por cilindro 

2 

4 

Setores por trilha 

9 

252 

Setores por disco 

720 

1056384 

Bytes por setor 

512 

512 

Bytes por disco 

368640 

540868608 

Tempo de busca (cilindros adjacentes) 

6ms 

4ms 

Tempo de busca (caso médio) 

77ms 

11 ms 

Tempo de rotação 

200ms 

13ms 

Tempo de parada/partida do motor 

250ms 

9s 

Tempo para transferir 1 setor 

22ms 

53ps 


Figura 3-19 Os parâmetros de disco para o disquete IBM PC original de 360KB e um disco 
rígido Western Digital WD AC2540 de 540MB. 
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Posição Solicitações 



Figura 3-20 Algoritmo de agendamento de disco busca mais curta primeiro (Shorlest Seek First - SSF). 


Quando a solicitação atual (para o cilindro 11) termi¬ 
na, o driver de disco pode escolher qual solicitação ele deve 
tratarem seguida. Utilizando FCFS, ele iria em seguida para 
o cilindro 1, depois para o 36 e assim por diante. Esse algo¬ 
ritmo exigiria movimentos de braço de 10, 35, 20, 18, 25 e 
3, respectivamente, em um total de 111 cilindros. 

Alternativamente, ele sempre poderia tratar a solicita¬ 
ção mais próxima a seguir, para minimizar o tempo de 
busca. Dadas as solicitações na Figura 3-20, a seqüência é 
12, 9, 16 , 1, 34 e 36, mostrada como uma linha serrilhada 
na parte inferior da Figura 3-20. Com essa seqüência, os 
movimentos de braço são 1, 3.7,15. 33 e 2, em um total de 
6l cilindros. Esse algoritmo, busca mais curta primeiro 
(Shorlest Seek First - SSF), reduz 0 movimento total de 
braço em quase metade se comparado com 0 FCFS. 

Infelizmente, 0 SSF tem um problema. Suponha que 
mais solicitações continuem chegando enquanto as solici¬ 
tações da Figura 3-2 0 estão sendo processadas. Por exem¬ 
plo, se, depois de ir para 0 cilindro 16 , uma nova solicita¬ 
ção para 0 cilindro 8 for feita, essa solicitação terá priori¬ 
dade sobre 0 cilindro 1. Se então chegar uma solicitação 
para 0 cilindro 13 , 0 braço irá em seguida para 13 em vez 
de 1. Com um disco muito carregado, 0 braço tenderá a 
permanecer no meio do disco a maior parte do tempo, por¬ 
tanto, as solicitações em qualquer extremo terão de espe¬ 
rar até que uma flutuação estatística na carga faça com 
que não haja nenhuma solicitação perto do meio. As soli¬ 
citações longe do meio podem obter um serviço deficiente. 
As metas de tempo mínimo de resposta e de imparcialidade 
estão em conflito aqui. 

Edifícios altos também precisam lidar com esse tipo de 
compensação. 0 problema de agendar um elevador em um 
edifício alto é semelhante ao do agendamento de um bra¬ 
ço de disco. As solicitações entram continuamente chaman¬ 
do 0 elevador para andares (cilindros) aleatórios. O micro¬ 
processador que controla 0 elevador poderia facilmente 
acompanhar a seqüência em que os clientes apertam 0 
botão de chamada e serviria-os, utilizando FCFS. Ele tam¬ 
bém poderia utilizar SSF. 


Entretanto, a maioria dos elevadores utiliza um algo¬ 
ritmo diferente para atender às exigências contraditórias 
de eficiência e de imparcialidade. Eles continuam a mo- 
ver-se na mesma direção até que não haja mais solicita¬ 
ções destacadas nessa direção; então, eles mudam de dire¬ 
ção. Esse algoritmo, conhecido tanto no mundo da com¬ 
putação como no mundo dos elevadores como algoritmo 
do elevador, requer que 0 software mantenha 1 bit: 0 bit 
de direção atual, up ou down. Quando uma solicitação ter¬ 
mina, 0 driver de disco ou de elevador verifica 0 bit. Se é 
UP, 0 braço ou a cabine é movido para a próxima solicita¬ 
ção acima. Se nenhuma solicitação está pendente em po¬ 
sições mais altas, 0 bit de direção é invertido. Quando 0 bit 
é configurado como DOWN, o movimento é para a próxima 
solicitação abaixo, se houver alguma. 

A Figura 3-21 mostra 0 algoritmo do elevador utilizan¬ 
do as mesmas sete solicitações da Figura 3-20, supondo 
que 0 bit de direção era inicialmente UP. A ordem em que 
os cilindros são servidos é 12 , 16 , 34,36, 9 e 1 ,0 que resulta 
em movimentos de braço de 1,4, 18, 2, 27 e 8, para um 
total de 60 cilindros. Nesse caso, 0 algoritmo do elevador é 
ligeiramente melhor do que 0 SSF, embora seja geralmen¬ 
te pior. Uma propriedade interessante que 0 algoritmo do 
elevador tem é que dada qualquer coleção de solicitações, 
0 limite superior para 0 movimento total é fixo: ele é sim¬ 
plesmente duas vezes 0 número de cilindros. 

Uma ligeira modificação desse algoritmo que tem uma 
variância menor nos tempos de resposta (Teory, 1972) é 
avançar sempre na mesma direção. Quando 0 cilindro com 
a numeração mais alta com uma solicitação pendente é 
servido, 0 braço vai para 0 cilindro com a numeração mais 
baixa com uma solicitação pendente e, então, continua a 
mover-se para cima. De fato, 0 cilindro com numeração 
mais baixa é simplesmente considerado como estando aci¬ 
ma do cilindro com numeração mais alta. 

Algumas controladoras de disco oferecem um modo de 
0 software inspecionar 0 número do setor atual sob 0 cabe¬ 
çote. Com uma controladora desse tipo, outra otimização é 
possível. Se duas ou mais solicitações para 0 mesmo cilin- 
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dro estiverem pendentes, o driver pode fazer uma solicita¬ 
ção para o setor que passará sob o cabeçote em seguida. 
Note que quando múltiplas trilhas estão presentes em um 
cilindro, podem ser feitas solicitações consecutivas para tri¬ 
lhas diferentes sem nenhuma penalidade. A controladora 
pode selecionar qualquer dos seus cabeçotes instantanea¬ 
mente, porque a seleção de cabeçote não envolve nenhum 
movimento de braço nem retardo rotacional. 

Com um disco rígido moderno, a taxa de transferência 
de dados é tão mais rápida que a de um disquete que al¬ 
gum tipo de cache automático é necessário. Geralmente 
qualquer solicitação de leitura de um setor faz com que 
esse setor e todo o resto da trilha atual seja lido, dependen¬ 
do de quanto espaço estiver disponível na memória de ca¬ 
che da controladora. 0 disco de 540M descrito na Figura 3- 
19 tem um cache de 64K ou de 128K. A utilização do cache 
é determinada dinamicamente pela controladora. Em seu 
modo mais simples, o cache é dividido em duas seções, uma 
para ler e uma para gravar 

Quando várias unidades estão presentes, uma tabela de 
solicitações pendentes deve ser mantida para cada unidade 
separadamente. Sempre que qualquer unidade está deso¬ 
cupada, deve ser feita uma busca para mover o seu braço 
para o cilindro onde será necessário em seguida (supondo 
que a controladora permite busca sobreposta). Quando a 
transferência atual terminar, uma verificação pode ser fei¬ 
ta para ver se qualquer unidade está posicionada no cilin¬ 
dro correto. Se uma ou mais estiverem, a próxima transfe¬ 
rência poderá ser iniciada em uma unidade que já está no 
cilindro correto. Se nenhum braço estiver no lugar certo, o 
driver deve fazer uma nova busca na unidade que acabou 
de completar uma transferência e esperar a interrupção 
seguinte para ver qual braço chega ao seu destino primei¬ 
ro. 

Tratamento de Erros 

Os discos de RAM não precisam preocupar-se com oti¬ 
mização rotacional ou de busca: em qualquer instante to¬ 
dos os blocos podem ser lidos ou gravados sem qualquer 


movimento físico. Outra área em que os discos de RAM são 
mais simples que os discos reais é o tratamento de erros. Os 
discos de RAM sempre funcionam: os reais nem sempre fun¬ 
cionam. Eles estão sujeitos a uma ampla variedade de er¬ 
ros. Alguns dos mais comuns são: 

1. Erro de programação (p. ex., solicitação para um 
setor inexistente). 

2. Erro transitório de soma de verificação (p.ex., cau¬ 
sado por pó no cabeçote). 

3. Erro permanente de soma de verificação (p. ex., 
bloco de disco fisicamente danificado). 

4. Erro de busca (p. ex., o cilindro foi enviado para o 
braço 6 mas acabou indo para o 7). 

5. Erro de controladora (p. ex., a controladora recu¬ 
sa-se a aceitar comandos). 

Cabe ao driver de disco tratar cada um desses erros da 
melhor maneira que puder. 

Os erros de programação ocorrem quando o driver ins¬ 
trui a controladora para buscar um cilindro inexistente, 
ler de um setor inexistente, utilizar um cabeçote inexisten¬ 
te ou transferir para ou de uma memória inexistente. A 
maioria das controladoras verifica os parâmetros forneci¬ 
dos e queixa-se se eles forem inválidos. Em teoria, esses 
erros nunca devem ocorrer, mas o que o driver deve fazer 
se a controladora indicar que aconteceu? Para um sistema 
doméstico, a melhor coisa a fazer é parar e imprimir uma 
mensagem como “Chame o programador” para que o erro 
possa ser verificado e corrigido. Para um produto comerci¬ 
al de software em utilização em milhares de pontos ao re¬ 
dor do mundo, essa abordagem é menos atraente. Prova¬ 
velmente a única coisa a fazer é encerrar a solicitação atu¬ 
al ao disco com um erro e esperar que ela não se repita 
com muita freqüência. 

Erros transitórios de soma de verificação são causados 
por partículas de pó no ar que acabam ficando entre o ca¬ 
beçote e a superfície de disco. A maioria das vezes, esses 
erros podem ser eliminados simplesmente repetindo-se a 
operação algumas vezes. Se o erro persistir, o bloco precisa 
ser marcado como um bloco defeituoso e evitado. 


Posição 

inicial 
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Figura 3-21 0 algoritmo do elevador para agendamento de solicitações de disco. 
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Uma maneira de evitar blocos defeituosos é escrever um 
programa muito especial que pega uma lista de blocos de¬ 
feituosos como entrada e cuidadosamente cria um arquivo 
que contém todos os blocos defeituosos. Uma vez que o ar¬ 
quivo tenha sido criado, o alocador de disco pensará que 
os blocos estão ocupados e nunca os atribuirá. Contanto 
que ninguém jamais tente ler o arquivo de blocos defeitu¬ 
osos, nenhum problema ocorrerá. 

Não ler o arquivo bloco defeituoso é mais fácil dizer do 
que fazer. Muitos discos são salvos em backup copiando-se 
seu conteúdo uma trilha por vez para uma unidade de dis¬ 
co ou fita de backup. Se esse procedimento for seguido, os 
blocos defeituosos causarão problema. Fazer backup do 
disco um arquivo por vez é mais lento mas resolverá o pro¬ 
blema, desde que o programa de backup saiba o nome do 
arquivo de blocos defeituosos e evite copiá-lo. 

Outro problema que não pode ser resolvido com um 
arquivo blocos defeituosos é um bloco defeituoso em uma 
estrutura de dados do sistema de arquivos que deve estar 
em uma posição fixa. Quase todos os sistemas de arquivos 
têm pelo menos uma estrutura de dados cuj a posição é fixa, 
assim ela pode ser localizada facilmente. Em um sistema 
de arquivos particionado pode ser possível reparticionar e 
contornar uma trilha defeituosa, mas um erro permanen¬ 
te nos primeiros setores de qualquer disquete ou disco rígi¬ 
do geralmente significa que o disco não é utilizável. 

Controladoras "inteligentes" reservam algumas trilhas 
normalmente não-disponíveis para programas de usuário. 
Quando uma unidade de disco é formatada, a controlado¬ 
ra determina quais blocos são defeituosos e automatica¬ 
mente substitui a trilha defeituosa por uma das trilhas de 
reserva. A tabela que mapeia trilhas defeituosas para tri¬ 
lhas de reserva é mantida na memória interna da contro¬ 
ladora e no disco. Essa substituição é transparente (invisí¬ 
vel) para o driver, exceto que seu algoritmo do elevador 
cuidadosamente elaborado pode ter um pobre desempenho 
se a controladora secretamente estiver utilizando o cilin¬ 
dro 800 sempre que cilindro 3 for solicitado. Hoje, a tecno¬ 
logia de fabricar superfícies de gravação de disco é melhor 
do que era antigamente, mas ainda não é perfeita. Entre¬ 
tanto, a tecnologia de esconder as imperfeições do usuário 
também melhorou. Em discos rígidos como o descrito na 
Figura 3-19, a controladora também gerencia novos erros 
que podem desenvolver-se com a utilização, atribuindo blo¬ 
cos substitutos permanentemente quando determina que 
um erro é irrecuperável. Com esses discos, o software de 
driver raramente vê qualquer indicação de que há quais¬ 
quer blocos defeituosos. 

Erros de busca são causados por problemas mecânicos 
no braço. A controladora monitora a posição do braço in¬ 
ternamente. Para realizar uma busca, ela emite uma série 
de pulsos para o motor do braço, um pulso por cilindro, 
para mover o braço para o novo cilindro. Quando o braço 
chega ao seu destino, a controladora lê o número real do 
cilindro (gravado quando a unidade foi formatada). Se o 
braço estiver no lugar errado, um erro de busca ocorreu. 


A maioria das controladoras de disco rígido corrige pro¬ 
blemas de busca automaticamente, mas muitas controla¬ 
doras de disquete (IBM-PCs inclusive) simplesmente con¬ 
figuram um bit de erro e deixam o resto para o driver, o 
qual trata esse erro dando um comando RECALIBRATE, para 
mover o braço o máximo possível para fora e redefinir a 
idéia interna que a controladora tem sobre o cilindro atual 
para 0. Normalmente isso resolve o problema. Se não, a 
unidade deve ser reparada. 

Como vimos, a controladora é realmente um pequeno 
computador especializado, completa com software, variá¬ 
veis, buffers e ocasionalmente, bugs. Às vezes, uma seqüên- 
cia única de eventos como uma interrupção em uma uni¬ 
dade ocorrendo simultaneamente com um comando RE- 
CALIBRATE para outra unidade desencadeará um erro e fará 
com que a controladora entre em um laço ou perca a tri¬ 
lha do que estava fazendo. Projetistas de controladoras nor¬ 
malmente planejam para o pior e oferecem um pino no 
chip que, quando conectado, força a controladora a esque¬ 
cer o que estava fazendo e reinicializar-se. Se tudo mais 
falhar, o driver de disco pode configurar um bit para invo¬ 
car esse sinal e chamar a controladora. Se isso não ajudar, 
tudo o que o driver pode fazer é imprimir uma mensagem 
e desistir. 

Fazendo Cache de uma Trilha por Vez 

O tempo necessário para buscar um novo cilindro é nor¬ 
malmente muito maior do que o retardo rotacional e sem¬ 
pre muito maior do que o tempo de transferência. Em ou¬ 
tras palavras, uma vez que o driver caiu no problema de 
mover o braço para algum lugar, dificilmente faz diferença 
se lê um setor ou uma trilha inteira. Esse efeito é especial¬ 
mente verdadeiro se a controladora oferece sensibilidade ro¬ 
tacional, então, o driver pode ver qual setor está atualmen¬ 
te sob o cabeçote e fazer uma solicitação para o próximo 
setor, tornando possível assim ler uma trilha por tempo de 
rotação. (Normalmente leva o tempo de meia rotação mais 
um setor somente para ler-se um único setor, em média.) 

Alguns drivers de disco tiram proveito dessa proprieda¬ 
de mantendo um cache secreto de uma trilha por vez, des¬ 
conhecido pelo software independente de dispositivo. Se 
uma seção que está no cache for solicitada, nenhuma trans¬ 
ferência de disco é necessária. Uma desvantagem de fazer 
cache uma trilha por vez (além da complexidade do sof¬ 
tware e do espaço de buffer necessários) é que as transfe¬ 
rências do cache para o programa que fez chamada terão 
de ser feitas pela CPU utilizando um laço programado, em 
vez de deixar o hardware de DMA fazer o trabalho. 

Algumas controladoras levam esse processo um passo 
adiante e fazem um cache de uma trilha por vez na pró¬ 
pria memória interna, transparente para o driver, de modo 
que as transferências entre a controladora e a memória 
podem utilizar DMA. Se a controladora trabalhar dessa 
maneira, há pouco sentido em ter o driver de disco fazen¬ 
do isso também. Note que ambos, a controladora e o dri- 
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ver, estão em uma boa posição para ler e para gravar tri¬ 
lhas inteiras em um comando, mas que o software inde¬ 
pendente de dispositivo não pode, porque ele considera um 
disco como uma seqüência de blocos linear, sem conside¬ 
rar como eles estão divididos em trilhas e em cilindros. 

3-7.3 Visão Geral do Driver de Disco 
Rígido no MINIX 

0 driver de disco rígido é a primeira parte do minix que 
vimos que precisa lidar com uma ampla variedade de tipos 
de hardware diferentes. Antes de discutirmos os detalhes do 
driver, consideraremos brevemente algumas diferenças de 
hardware que podem causar problemas. 0 “IBM PC é re¬ 
almente uma família de computadores diferentes. Além de 
processadores diferentes utilizados em membros diferentes 
da família, também há algumas diferenças importantes no 
hardware básico. Os membros mais antigos da família, 0 
PC original e 0 PC-XT, utilizavam um barramento de 8 
bits, apropriado para a interface externa de 8 bits do pro¬ 
cessador 8088. A geração seguinte, 0 PC-AT, utilizava um 
barramento de 16 bits, que foi inteligentemente projetado 
de tal modo que periféricos de 8 bits mais antigos ainda 
podiam ser utilizados. Contudo, os periféricos de l6 bits 
mais novos geralmente não podem ser utilizados em siste¬ 
mas PC-XT mais antigos. O barramento AT foi projetado 
originalmente para sistemas que utilizavam 0 processador 
80286 e muitos sistemas baseados nos 80386, 80486 e 0 
Pentium utilizam 0 barramento AT. Entretanto, como es¬ 
ses processadores mais novos têm uma interface de 32 bits, 
agora há vários sistemas de barramentos de 32 bits dife¬ 
rentes disponíveis, como 0 barramento PCI da Intel. 

Para cada barramento, há uma família diferente de 
adaptadores de E/S, que são conectados na parentboard 
do sistema. Todo 0 periférico para um projeto particular de 
barramento deve ser compatível com os padrões desse pro¬ 
jeto mas não precisa ser compatível com projetos mais an¬ 
tigos. Na família IBM PC, como na maioria dos outros sis¬ 
temas de computador, cada projeto de barramento tam¬ 
bém vem com firmware no Basic I/O System Read Only 
Memory (0 BIOS ROM) que é projetado para preencher a 
lacuna entre 0 sistema operacional e as peculiaridades do 
hardware. Alguns dispositivos periféricos podem oferecer 
extensões para 0 BIOS em chips de ROM nas próprias pla¬ 
cas periféricas. A dificuldade com que se defronta um im¬ 
plementador de sistema operacional é que 0 BIOS em com¬ 
putadores do tipo IBM (certamente os primeiros) foi proje¬ 
tado para um sistema operacional, MS-DOS, que não supor¬ 
ta multiprogramação e que executa no modo real de 16 
bits, 0 mais baixo denominador comum dos vários modos 
de operação disponíveis na família de CPUs 80x86. 

O implementador de um novo sistema operacional para 
IBM PC defronta-se, portanto, com várias opções. Uma é 
utilizar 0 suporte de driver para periféricos no BIOS ou 
escrever novos drivers a partir do zero. Isso não era uma 
escolha difícil no projeto original do MINIX, uma vez que 0 
BIOS, sob vários aspectos, não era adequado às necessida¬ 


des do minix. Naturalmente, para ser iniciado, 0 monitor 
de inicialização do minix utiliza 0 BIOS para fazer a carga 
inicial do sistema, seja de um disco rígido ou de um dis¬ 
quete — não há uma alternativa prática para fazer isso 
dessa maneira. Uma vez que carregamos 0 sistema, inclu¬ 
indo os próprios drivers de E/S, podemos fazer muito me¬ 
lhor que 0 BIOS. 

A segunda escolha, então, deve ser encarada: sem 0 su¬ 
porte de BIOS como faremos nossos drivers adaptarem-se 
aos vários tipos de hardware em sistemas diferentes? Para 
tornar a discussão concreta, considere que há pelo menos 
quatro tipos de controladoras de disco rígido fundamen¬ 
talmente diferentes que podemos encontrar em um siste¬ 
ma e que, a princípio, seriam adequados ao minix: a con¬ 
troladora do tipo XT de 8 bits original, a controladora do 
tipo AT de l6 bits e duas controladoras diferentes para dois 
tipos diferentes de computador da série IBM PS/2. Há vári¬ 
as maneiras possíveis de lidar com isso: 

1. Recompilar uma versão única do sistema operaci¬ 
onal para cada tipo de controladora de disco rígi¬ 
do a que precisamos adaptar-nos. 

2. Compilar vários drivers de disco rígido diferentes 
no kernel e fazer 0 kernel automaticamente deter¬ 
minar em tempo de inicialização qual utilizar. 

3. Compilar vários drivers de disco rígido diferentes 
no kernel e proporcionar um meio para 0 usuário 
determinar qual utilizar. 

Como veremos, tais alternativas não são mutuamente ex¬ 
clusivas. 

A primeira é realmente a melhor opção a longo prazo. 
Para utilização em uma instalação particular não há ne¬ 
nhuma necessidade de consumir espaço em disco e me¬ 
mória com código para drivers alternativos que jamais se¬ 
rão utilizados. Entretanto, é um pesadelo para 0 fabricante 
do software. Fornecer quatro discos diferentes de iniciali¬ 
zação, e instruir os usuários sobre como utilizá-los é caro e 
difícil. Assim, uma das outras alternativas é aconselhável, 
pelo menos para a instalação inicial. 

O segundo método é fazer 0 sistema operacional inves¬ 
tigar os periféricos, lendo 0 ROM em cada placa ou gra¬ 
vando e lendo portas de E/S para identificar cada placa. 
Isso é praticável em alguns sistemas, mas não funciona 
bem em sistemas tipo IBM porque grande parte dos dispo¬ 
sitivos de E/S disponíveis não são padrão. Investigar as por¬ 
tas de E/S para identificar um dispositivo pode, em alguns 
casos, ativar outro dispositivo que assuma 0 controle e de¬ 
sative 0 sistema. Esse método complica 0 código de inicia¬ 
lização para cada dispositivo e além disso não funciona 
muito bem. Os sistemas operacionais que utilizam esse 
método geralmente precisam oferecer algum tipo de so¬ 
breposição, normalmente um mecanismo como 0 que uti¬ 
lizamos no MINIX. 

O terceiro método, utilizado no MINIX, é permitir a com¬ 
pilação de vários drivers, com um deles sendo 0 padrão. 0 
monitor de inicialização do minix permite que vários pa¬ 
râmetros de inicialização sejam lidos em tempo de ini- 
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cialização. Esses parâmetros podem ser inseridos manual¬ 
mente ou armazenados permanentemente no disco. Em 
tempo inicialização, se um parâmetro de inicialização na 
forma de: 

hd = xt 

for localizado, isso forçará a utilização do driver de disco 
rígido XT. Se parâmetro de inicialização hd não for encon¬ 
trado o driver padrão é utilizado. 

Há duas outras coisas que o MINIX faz para tentar mini¬ 
mizar problemas com múltiplos drivers de disco rígido. 
Uma é que há, no final das contas, um driver que faz in¬ 
terface entre o MlNix e o suporte de disco rígido do ROM 
BIOS. Esse driver provavelmente funcionará em qualquer 
sistema e pode ser selecionado por utilização de um parâ¬ 
metro 

hd = bios 

na inicialização. Entretanto, em geral, isso deve ser utili¬ 
zado como um último recurso. 0 MINIX executa em modo 
protegido em sistemas com um processador 80286 ou su¬ 
perior, mas o código de BIOS sempre executa em modo real 
(8086). Entrar e sair do modo protegido sempre que uma 
rotina do BIOS é chamada é muito lento. 

A outra estratégia que o MINIX utiliza ao lidar com dri¬ 
vers é adiar a inicialização até o último momento possível. 
Assim, se em uma determinada configuração de hardware 
nenhum dos drivers de disco rígido funcionar, ainda pode¬ 
mos iniciar o MINIX a partir de um disquete e fazer algum 
trabalho útil. O MINIX não terá nenhum problema contan¬ 
to que não precise acessar o disco rígido. Isso pode não 
parecer um avanço importante na interface com o usuá¬ 
rio, mas considere isso: se todos os drivers tentarem iniciar 
de uma vez ao inicializarmos o sistema, o sistema pode ser 
totalmente paralisado por configuração imprópria de al¬ 
gum dispositivo do qual não precisaremos no final das con¬ 
tas. Adiando a inicialização de cada driver até que seja 
necessário, o sistema pode continuar com o que funciona, 
enquanto o usuário tenta resolver os problemas. 

A propósito, aprendemos essa lição do jeito mais difícil: 
versões anteriores do MINIX tentavam iniciar o disco rígido 
logo que o sistema era inicializado. Se disco rígido não es¬ 
tivesse presente, o sistema era suspenso. Esse comportamen¬ 
to era especialmente infeliz porque o MINIX rodará feliz em 
um sistema sem disco rígido, embora com capacidade de 
armazenamento restrita e desempenho reduzido. 

Na discussão desta e da próxima seção, tomaremos 
como modelo o driver de disco rígido estilo AT, que é o 
flWfer-padrão na versão padrão de distribuição do MINIX. 
Trata-se de um driver versátil que gerencia desde as con¬ 
troladoras de disco rígido utilizadas nos antigos sistemas 
80286 até as modernas controladoras EIDE (Extended 
Integrated Drive Electronics) que gerenciam discos rí¬ 
gidos com capacidades na ordem dos gigabytes. Os aspec¬ 
tos gerais da operação do disco rígido que discutimos nesta 
seção aplicam-se também aos outros drivers suportados. 


O laço principal da tarefa de disco rígido é o mesmo 
código compartilhado que já discutimos, e os seis tipos- 
padrão de solicitações podem ser feitos. A solicitação 
DEVJ3PEN pode envolver uma quantidade substancial de 
trabalho, uma vez que sempre há partições e talvez haja 
subpartições em um disco rígido. Essas devem ser lidas 
quando um dispositivo é aberto, (i. e., quando é acessado 
pela primeira vez). Algumas controladoras de disco rígido 
também podem suportar unidades de CDROM. que têm 
mídia removível, e em um DEVJDPEN a presença da mí¬ 
dia deve ser verificada. Em um CD-ROM uma operação 
DEVjOLOSE também tem significado: ela requer que a porta 
seja desbloqueada e o CD-ROM removido. Há outras com¬ 
plicações de mídia removível que são mais aplicáveis a 
unidades de disquete, portanto, discutiremos essas em uma 
seção mais adiante. Para o disco rígido a operação 
DEVJOCTL é utilizada para configurar um sinalizador a 
fim de assinalar que a mídia que deve ser removida em 
uma DE\'_CLOSE. Esse recurso é útil para CD-ROMs. E tam¬ 
bém é utilizado para ler e para gravar tabelas de partição, 
como mencionado anteriormente. 

As solicitações DEAJREAD, DEV_WRÍIE e SCATTERED_ 
IO são tratadas em três fases, preparação, agendamento e 
término, como vimos. O disco rígido, ao contrário dos dis¬ 
positivos de memória, faz uma distinção real entre as fases 
de agendamento e término. O driver de disco rígido não 
utiliza SSF nem o algoritmo do elevador, mas realiza uma 
forma mais limitada de agendamento, reunindo solicita¬ 
ções a setores consecutivos. As solicitações normalmente 
vêm do sistema de arquivos MINIX e são para múltiplos blo¬ 
cos de 1024 bytes, mas o driver é capaz de tratar solicita¬ 
ções para qualquer múltiplo de um setor (512 bytes). Con¬ 
tanto que cada solicitação seja para um setor imediata¬ 
mente seguinte ao último setor requisitado, cada solicita¬ 
ção é anexada a uma lista de solicitações. A lista é mantida 
como uma matriz e quando estiver cheia ou quando um 
setor não-consecutivo for solicitado, é feita uma chamada 
para a rotina de término. 

Em uma simples solicitação DEV_READ ou DEV_ 
WRITE, mais de um bloco pode ser solicitado, mas cada 
chamada à rotina de agendamento é imediatamente se¬ 
guida por uma chamada à rotina de término, o que asse¬ 
gura que a lista atual de solicitações seja atendida. No caso 
de uma solicitação SCATTEREDJO, pode haver múltiplas 
chamadas à rotina de agendamento antes de a rotina de 
término ser chamada. Contanto que seja para blocos con¬ 
secutivos de dados, a lista será estendida até que a matriz 
esteja cheia. Lembre-se de que, em uma solicitação 
SCATTEREDJO, um sinalizador pode significar que uma 
solicitação para um bloco particular é opcional. O driver 
de disco rígido, como o driver de memória, ignora o sina¬ 
lizador OPTIONAL e entrega todos os dados solicitados. 

O agendamento rudimentar realizado pelo driver de 
disco rígido, adiando as transferências reais enquanto blo¬ 
cos consecutivos estão sendo solicitados, deve ser visto como 
o segundo passo de um potencial processo de três passos de 
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agendamento. 0 próprio sistema de arquivos, utilizando 
E/S dispersa, pode implementar algo semelhante para a 
versão de Teory do algoritmo do elevador — lembre-se de 
que em uma E/S dispersa a lista de solicitações é classifica¬ 
da segundo o número de bloco. 0 terceiro passo no agen¬ 
damento acontece na controladora de um disco rígido mo¬ 
derno, como o descrito na Figura 3-19- Essas controladoras 
são “espertas” e podem bufferizar grandes quantidades de 
dados, utilizando algoritmos programados internamente 
para recuperar dados na ordem mais eficiente, independen¬ 
temente da ordem de recebimento das solicitações. 

3.7.4 A Implementação do Driver de 
Disco Rígido no MINIX 

Discos rígidos pequenos utilizados em microcomputa¬ 
dores, às vezes, são chamados uinchesters. Há várias histó¬ 
rias diferentes sobre a origem do nome. Aparentemente, era 
um nome de código da IBM para o projeto que desenvol¬ 
veu a tecnologia de disco em que os cabeçotes de leitura/ 
gravação flutuam sobre uma fina almofada de ar e pou¬ 
sam na mídia de gravação quando o disco pára de girar. 
Uma explicação do nome é que um modelo anterior tinha 
dois módulos de dados, um de 30 Mbytes fixo e um removí¬ 
vel de 30 Mbytes. Supostamente isso lembrava aos desen¬ 
volvedores as antigas armas Winchester 30-30 que figura¬ 
vam em muitas histórias de faroeste. Qualquer que seja a 
origem do nome, a tecnologia básica permanece a mesma, 
embora hoje um típico disco de microcomputador seja 
muito menor e a capacidade seja muito maior do que os 
discos de 14 polegadas que eram típicos no começo da dé¬ 
cada de 70 quando a tecnologia dos u inchesters foi desen¬ 
volvida. 

O arquivo tvini.c tem o trabalho de ocultar o driver de 
disco rígido utilizado do resto do kernel. Isso nos permite 
seguir a estratégia discutida na seção anterior, compilando 
vários drivers de disco rígido em uma única imagem de 
kernel e selecionar um em tempo de inicialização. Mais 
tarde, uma instalação personalizada pode ser recompilada 
com apenas o driver realmente necessário. 

Wini.c contém uma definição de dados, hdmap (linha 
10013), uma matriz que associa um nome com o endereço 
de uma função. A matriz é iniciada pelo compilador com 
quantos elementos forem necessitados pelo número de dri¬ 
vers de disco rígido ativados em íncluded/minix/config.h. 
A matriz é utilizada pela função Winchester Jask, que é o 
nome inserido na tabela taskjab utilizada quando o ker¬ 
nel é iniciado pela primeira vez. Quando Winchester_task 
(linha 10040) é chamada, ela tenta localizar uma variável 
de ambiente hd, utilizando uma função de kernel que fun¬ 
ciona de maneira semelhante ao mecanismo utilizado por 
programas normais em C, lendo o ambiente criado pelo 
monitor de inicialização do MINIX. Se o valor de hd não 
estiver definido, a primeira entrada na matriz será utiliza¬ 
da; caso contrário, ela é pesquisada quanto a um nome 
que coincida. A função correspondente, então, é chamada 
de maneira indireta. No restante desta seção, discutiremos 


o at_winchester_task, que é a primeira entrada na matriz 
hdmap na distribuição padrão do MINIX. 

O driver estilo AT estáem«/_«7'w/.c (linha 10100). Esse 
é um driver complicado para um dispositivo sofisticado e 
há várias páginas de definições de macros para especificar 
registradores de controladora, bits de status e comandos, 
estruturas de dados e protótipos. Como com outros drivers 
de dispositivo de bloco, uma estrutura driver, w_dtab (li¬ 
nhas 10274 para 10284) é iniciada com ponteiros para as 
funções que realmente fazem o trabalho. A maioria delas é 
definida em atjwini.c , mas como o disco rígido não re¬ 
quer nenhuma operação especial de limpeza, sua entrada 
dr_cleanup aponta para nopjcleanup comum em 
driver, c. compartilhado com outros drivers que não fazem 
nenhuma exigência especial de limpeza. A função de en¬ 
trada, atjuinchester Jask (linha 10294), chama um pro¬ 
cedimento que faz inicialização específica de hardware e, 
então, chama o laço principal em driver c. Este último exe¬ 
cuta eternamente, despachando chamadas para as várias 
funções apontadas pela tabela driver. 

Como agora estamos lidando com dispositivos de ar¬ 
mazenamento eletromecânicos reais, há uma quantidade 
substancial de trabalho a ser feito para iniciar o driver de 
disco rígido. Vários parâmetros sobre os discos rígidos são 
mantidos na matriz uini definida nas linhas 10214 a 10230. 
Como parte da política de adiar passos de inicialização que 
possam falhar até quando eles forem realmente necessári¬ 
os, init_params (linha 10307), que é chamado durante a 
inicialização do kernel , não faz nada que exija acessar o 
dispositivo de disco. A principal coisa que ele faz é copiar 
algumas informações sobre a configuração lógica do disco 
rígido na matriz uini. Essas são as informações recupera¬ 
das pelo ROM BIOS da memória CMOS que os computado¬ 
res da classe Pentium utilizam para preservar dados bási¬ 
cos de configuração. As ações do BIOS acontecem quando 
o computador é ligado, antes de a primeira parte do pro¬ 
cesso de carregamento do minix começar. Não é necessari¬ 
amente fatal se tais informações não puderem ser recupe¬ 
radas; se o disco for um disco moderno, as informações 
podem ser recuperadas diretamente dele. 

Após a chamada ao laço principal comum, nada pode 
acontecer temporariamente até que uma tentativa seja fei¬ 
ta para acessar o disco rígido. Então, uma mensagem soli¬ 
citando uma operação DEVJDPENé recebida e w_do_open 
(linha 10355) é indiretamente chamada. Por sua vez, 
w_do_ open chama w_prepare para determinar se o dis¬ 
positivo solicitado é válido, e então wjdentify para identi¬ 
ficar o tipo de dispositivo e iniciar alguns parâmetros adi¬ 
cionais na matriz wini. Por fim um contador na matriz 
uini é utilizado para testar se essa é a primeira vez que o 
dispositivo foi aberto desde que o MINIX foi iniciado. Depois 
de ser examinado, o contador é incrementado. Se essa for a 
primeira operação DEV_OPEN, a função partition (em 
drvlib.c ) é chamada. 

Aproxima função, w_prepare (linha 10388), aceita um 
argumento de número inteiro, device, que é o número de 
dispositivo secundário da unidade ou da partição a ser uti- 
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lizado e retorna um ponteiro para a estrutura device que 
indica o endereço de base e o tamanho do dispositivo. Em 
C, a utilização de um identificador para nomear uma es¬ 
trutura não impede a utilização do mesmo identificador 
para nomear uma variável. Se um dispositivo é uma uni¬ 
dade, uma partição ou subpartição pode ser determinado a 
partir do número do dispositivo secundário. Uma vez que 
w_prepare tenha completado seu trabalho, nenhuma das 
outras funções utilizadas para ler ou para gravar no disco 
precisa preocupar-se com o particionamento. Como vimos, 
w_prepare é chamada quando uma solicitação DEVJJPEN 
e' feita; também é uma fase do ciclo preparação/agenda- 
mento/término utilizado por toda solicitação de transfe¬ 
rência de dados. Nesse contexto sua inicialização de 
w_count para zero é importante. 

Discos compatíveis com software do tipo AT estiveram 
em utilização por um bom tempo e w_identify (linha 
10415) precisa distinguir entre diversos projetos diferentes 
que foram apresentados ao longo dos anos. O primeiro passo 
é ver se existe uma porta de E/S legível e gravável onde 
uma deveria existir em todas as controladoras de disco nessa 
família (linhas 10435 a 10437). Se essa condição for satis¬ 
feita, o endereço do manipulador de interrupções do disco 
rígido é instalado na tabela de descritores de interrupções, 
e o controlador de interrupções é ativado para responder a 
essa interrupção. Então, um commáoATAJDENTIFYé en¬ 
viado para a controladora de disco. Se o resultado for OK ., 
várias informações são recuperadas, incluindo uma string 
que identifica o modelo do disco e os parâmetros físicos de 
cilindro, cabeçote e setor para o dispositivo. (Note que a 
configuração “física" informada pode não ser a configu¬ 
ração física verdadeira, mas não temos nenhuma alterna¬ 
tiva a não ser aceitar o que a unidade de disco declara.) As 
informações de disco também indicam se o disco é capaz 
de Endereçamento Linear de Bloco (LBA — Linear 
Block Addressing) . Se for, o driver poderá ignorar os pa¬ 
râmetros de cilindro, cabeçote e setor e pode endereçar o 
disco utilizando números absolutos de setor, que é muito 
mais simples. 

Como mencionamos anteriormente, é possível que 
init_params não possa recuperar a configuração lógica 
de disco das tabelas de BIOS. Se isso acontecer, o código 
nas linhas 10469 a 10477 tentará criar um conjunto apro¬ 
priado de parâmetros com base no que ele lê da própria 
unidade. A idéia é que os números máximos de cilindro, 
cabeçote e setor podem ser 1023, 255 e 63 respectivamente, 
devido ao número de bits permitido para esses campos nas 
estruturas de dados originais do BIOS. 

Se o comando ATAJDENTIFY falhar, isso pode signifi¬ 
car simplesmente que o disco é um modelo mais antigo 
que não suporta o comando. Nesse caso, os valores lógicos 
de configuração previamente lidos por init_params é tudo 
que temos. Se forem válidos, eles são copiados para os cam¬ 
pos de parâmetro físicos de tvini; Caso contrário, um erro é 
retornado, e o disco não é utilizável. 


Por fim, o MIMX utiliza uma variável u32_t para con¬ 
tar os endereços em bytes. O tamanho de dispositivo que o 
driver pode tratar, expresso como uma contagem de seto¬ 
res, deve ser limitado se o produto de cilindros x cabeçotes 
x setores for muito grande (linha 10490). Embora à época 
em que este código foi escrito dispositivos de capacidade de 
4 GB raramente fossem encontrados em máquinas onde se 
poderia esperar que o MINIX fosse utilizado, a experiência 
ensinou que se deve escrever software para testar limites 
como esse, por mais que esses testes pudessem parecer des¬ 
necessários à época em que o código foi escrito. A base e o 
tamanho da unidade inteira, então, são inseridos na ma¬ 
triz wind. e w_specify é chamada, duas vezes se necessário, 
para passar de volta à controladora de disco os parâmetros 
a serem utilizados. Por fim, o nome do dispositivo (deter¬ 
minado por w_name) e a string de identificação localiza¬ 
da por identify (se for um dispositivo avançado) ou os pa¬ 
râmetros de cabeçote, cilindro e setor informados pelo BIOS 
(se for um dispositivo antigo) são impressos no console. 

W_name (linha 10511) retoma um ponteiro para uma 
string que contém o nome do dispositivo, que será “at-hd0”, 
“at-hd5”, “at-hdl0" ou “at-hdl5”. W_specify (linha 
10531), além de passar os parâmetros à controladora, tam¬ 
bém recalibra a unidade (se é um modelo mais antigo), 
fazendo uma busca para o cilindro zero. 

Agora estamos prontos para discutir as funções chama¬ 
das para atender uma solicitação de transferência de da¬ 
dos. WJtrepare, que já discutimos, é chamada primeiro. 
Sua inicialização da variável w_count para zero é impor¬ 
tante aqui. A próxima função chamada durante uma trans¬ 
ferência é w_schedule (linha 10567). Ela configura os pa¬ 
râmetros básicos: de onde os dados vêm, para onde irão, a 
contagem de bytes a transferir (que deve ser um múltiplo 
do tamanho de setor, o que é testado na linha 10584) e se a 
transferência é uma leitura ou uma gravação. O bit que 
pode estar presente em uma solicitação SCATTEREDJO para 
indicar uma transferência opcional é redefinido no código 
de operação a ser passado para a controladora (linha 
10595), mas note que ele é retido no campo io_request da 
estrutura iorequestjs. Para o disco rígido, é feita uma ten¬ 
tativa de atender todas as solicitações, mas, como veremos, 
o driver pode, mais tarde, decidir não fazer isso se houver 
erros. A última coisa na configuração é verificar se a solici¬ 
tação não vai além do último byte no dispositivo e reduzir 
a solicitação se for. Nesse ponto, o primeiro setor a ser lido 
pode ser calculado. 

Na linha 10602, o processo de agendamento começa 
realmente. Se já houver solicitações pendentes (testado ven¬ 
do-se se w_count é maior que zero) e se o setor a ser lido 
em seguida não é consecutivo ao último solicitado, então 
w_Jinish é chamada para completar as solicitações ante¬ 
riores. Caso contrário, w_nextblock, que armazena o nú¬ 
mero de setor do próximo setor, é atualizada, e o laço nas 
linhas 106 l 1 a 10640 é iniciado para adicionar novas soli¬ 
citações de setor à matriz de solicitações. O laço continua 
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até que o número máximo admissível de solicitações seja 
atingido (linha 106l4). O limite é mantido em uma variá¬ 
vel, max_count , uma vez que, como veremos mais adian¬ 
te, às vezes, é útil ser possível de ajustar o limite. Aqui no¬ 
vamente pode ocorrer uma chamada para w_flnish. 

Como vimos, há dois lugares dentro de wjrepare nos 
quais uma chamada a wjinish pode ser feita. Normal¬ 
mente w_prepare termina sem á\m\-àx wjinish, mas seja 
ou não chamada a partir de wjrepare, w_finisb (linha 
10649) sempre acaba sendo chamada a partir do laço prin¬ 
cipal em driver.c. Se ela acabou de ser chamada, pode não 
ter nada a fazer; então, há um teste na linha 10659 para 
verificar isso. Se ainda houver solicitações na matriz de 
solicitações, a parte principal de wjinish é iniciada. 

Como se poderia esperar, uma vez que pode haver um 
número considerável de solicitações enfileiradas, a parte 
principal de wjinish é um laço, nas linhas 10664 a 10761. 
Antes de iniciar o laço, a variável r é predefinida para um 
valor que significa um erro, para forçar a reinicialização 
da controladora. Se uma chamada a w_specifv sucede à 
estrutura command. cmd é inicializado para fazer uma 
transferência. Essa estrutura é utilizada para passar todos 
os parâmetros necessários à função que realmente opera a 
controladora de disco. O parâmetro cmd.precomp é utili¬ 
zado por algumas unidades para compensar algumas dife¬ 
renças no desempenho de gravação da mídia magnética 
com diferenças na velocidade da passagem da mídia sob os 
cabeçotes de disco à medida que eles se movem dos cilin¬ 
dros mais exteriores para os mais interiores. Ele é sempre o 
mesmo para uma unidade particular e é ignorado por mui¬ 
tas unidades. Cmd.count recebe o número de setores a trans¬ 
ferir. mascarado para uma quantidade que se ajusta em um 
byte de 8 bits, uma vez que este é o tamanho de todos os 
registradores de comandos e de status da controladora. O 
código nas linhas 10675 a 10689 especifica o primeiro setor 
a transferir, seja como um número de bloco lógico de 28 
bits (linhas 10676 a 10679) ou como parâmetros de cilin¬ 
dro, cabeçote e setor (linhas 10681 a 10688). Em qualquer 
caso, os mesmos campos na estrutura cmd são utilizados. 

Por fim, o próprio comando, de leitura ou gravação, é 
carregado e com_out é chamada na linha 10692 para ini¬ 
ciar a transferência. A chamada com_out pode falhar se a 
controladora não estiver pronta ou não ficar pronta dentro 
de um período predefinido. Nesse caso, a contagem de er¬ 
ros é incrementada, e a tentativa é abortada se MAX_ ER- 
RORS for alcançado. Caso contrário, a declaração 

continue; 

na linha 10697 faz o laço iniciar novamente na linha 
10665. 

Se a controladora aceitar o comando passado na cha¬ 
mada para com_out, pode demorar um pouco até os da¬ 
dos estarem disponíveis, portanto (supondo que o coman¬ 
do é DEVJEAD) w_intr_waité chamada na linha 10706. 
Discutiremos essa função detalhadamente mais tarde, mas, 
por enquanto, observe apenas que ela chama receive, por¬ 
tanto, neste ponto a tarefa de disco é bloqueada. 


Algum tempo mais tarde, mais ou menos, dependendo 
de uma busca estar ou não envolvida, a chamada a 
wjitrjvait retornará. Esse driver não utiliza DMA, em¬ 
bora algumas controladoras suportem-no. Em vez disso, é 
utilizada E/S programada. Se não houver nenhum erro re¬ 
tornado de w_intr_wait, a função de linguagem de as- 
semblyport_read irá tmnsíenv SECTOR JIZE bytes de da¬ 
dos da porta de dados da controladora para seu destino fi¬ 
nal, que deve ser um buffer no cache de blocos do sistema 
de arquivos. Em seguida, vários endereços e contagens são 
ajustados para registrar a transferência bem-sucedida. Por 
fim, se a contagem de bytes na solicitação atual for para 
zero, o ponteiro para a matriz de solicitações é avançado 
para apontar para a próxima solicitação (linha 10714). 

No caso de um comando DEVJVRITE, a primeira par¬ 
te, configurar os parâmetros de comando e enviar o co¬ 
mando à controladora, é a mesma que para uma leitura, 
exceto para o código de operação do comando. Entretanto, 
a ordem dos eventos subseqüentes é diferente para uma 
gravação. Primeiro, há uma espera para a controladora 
sinalizar que está pronta para receber os dados (linha 
10724). Waíifor é uma macro e normalmente retornará 
muito rapidamente. Falaremos mais sobre ela mais tarde; 
por enquanto, apenas observaremos que a espera poderá 
eventualmente atingir o tempo-limite, mas retardos lon¬ 
gos são extremamente raros. Então, os dados são transferi¬ 
dos da memória para a porta de dados da controladora uti¬ 
lizando port_write (linha 10729) e neste ponto w_intr_ 
waité chamada, e a tarefa de disco é bloqueada. Quando a 
interrupção chega e a tarefa de disco é acordada, a conta¬ 
bilização é feita (linhas 10736 a 10739)• 

Por fim, se houve erros na leitura ou gravação, eles de¬ 
vem ser tratados. Se a controladora informa o driver de 
que o erro foi devido a um setor defeituoso, não há ne¬ 
nhum sentido em tentar novamente, mas outros tipos de 
erro merecem uma nova tentativa, pelo menos até um pon¬ 
to. Esse ponto é determinado contando-se os erros e desis¬ 
tindo se MAXJRRORS for alcançado. Quando MAX_ 
ERRORS/2 é alcançado, w _need_reset é chamada para 
forçar a reinicialização quando a nova tentativa for feita. 
Entretanto, se a solicitação era originalmente opcional (fei¬ 
ta por uma solicitação SCATTERED JO) , nenhuma nova 
tentativa é feita. 

Se wjinish terminar sem erros ou devido a um erro, a 
variável w_command é sempre configurada como 
CMDJDLE. Isso permite que outras funções determinem 
se a falha não se deveu a um mau funcionamento mecâni¬ 
co ou elétrico do próprio disco causando uma falha na ge¬ 
ração de uma interrupção após uma tentativa de operação. 

A controladora de disco é controlada por um conjunto 
de registradores, que podem ser mapeados em memória em 
alguns sistemas, mas em um sistema compatível com IBM 
aparecem como portas de E/S. Os registradores utilizados 
por uma controladora de disco rígido padrão da classe de 
IBM-AT são mostrados na Figura 3-22. 

Este é nosso primeiro encontro com hardware de E/S e 
pode ser útil mencionar que algumas portas de E/S com- 
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portam-se diferentemente dos endereços de memória. Em 
geral, registradores de entrada e saída que eventualmente 
têm o mesmo endereço de porta de E/S não são o mesmo 
registrador. Assim, os dados gravados em um endereço par¬ 
ticular podem não ser necessariamente recuperados por 
uma subsequente operação de leitura. Por exemplo, o últi¬ 
mo endereço de registrador mostrado na Figura 3-22 mos¬ 
tra o status da controladora de disco durante uma leitura e 
é utilizado para enviar comandos para a controladora du¬ 
rante uma gravação. Também se sabe que o simples ato de 
ler e de escrever em um registrador de um dispositivo de E/ 
S causa a ocorrência de uma ação, independentemente dos 
detalhes dos dados transferidos. Isso é verdade quanto ao 
registrador de comando na controladora de disco AT. Em 
uso, dados são gravados nos registradores de numeração 
inferior para selecionar o endereço do disco a ser lido ou 
gravado e, então, gravar-se no registrador de comando um 
código de operação. 0 ato de gravar o código de operação 
no registrador de comando inicia a operação. 


Esse também é o caso em que a utilização de alguns 
registradores ou de campos nos registradores pode variar 
de acordo com os diferentes modos de operação. No exem¬ 
plo dado na figura, a gravação de um 0 ou um 1 no bit de 
LBA, bit 6 do registrador 6, seleciona se é utilizado o modo 
CHS (cilindro, cabeçote e setor - Cylinder-Head-Sector) 
ou LBA. Os dados gravados ou lidos dos registradores 3.4 e 5 
e os quatro bits inferiores do registrador 6 são interpretados 
diferentemente de acordo com a configuração do bit de LBA. 

Agora vejamos como um comando é enviado para a 
controladora chamando com_out (linha 10771). Antes de 
mudar qualquer registrador, o registrador de status é lido 
para determinar se a controladora não está ocupada. Isso é 
feito testando o bit STATUS_BSY. A velocidade é importante 
aqui e normalmente a controladora de disco está pronta 
ou estará pronta em breve, assim é utilizada espera ativa. 
Na linha 10779, waitfor é chamada para testar STATUSJSS)’. 
Para maximizar a velocidade de resposta, waitfor é uma 
macro, definida na linha 10268. Ela faz o teste necessário 


Registrador 

Função Read 

Função Write 

0 

Dados 

Dados 

1 

Erro 

Write Precompensation 

2 

Contagem de Setores 

Contagem de Setores 

3 

Número do Setor (0-7) 

Número do Setor (0-7) 

4 

Cilindro (Baixo) (8-15) 

Cilindro (Baixo) (8-15) 

5 

Cilindro (Alto) (16-23) 

Cilindro (Alto) (16-23) 

6 

Seleção de Unidade/Cabeçote (24-27) 

Seleção de Unidade/Cabeçote (24-27) 

7 

Status 

Comando 


(a) 


7 

6 

5 

4 

3 

2 

1 

0 

1 

LBA 

1 

D 

HS3 

HS2 

HS1 

HS0 


LBA: 0 = Modo de cilindro/cabeçote/setor (CHS) 

1 = Modo de endereçamento de bloco lógico (LBA) 

D: 0 = unidade mestre 

1 = unidade escrava 

HSn: Modo CHS: Seleciona cabeçote, no modo CHS 
Modo LBA: Seleciona bloco (bits 24 - 27) 
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Figura 3-22 (a) Os registradores de controle de uma controladora de disco rígido IDE. Os números entre 

parênteses são os bits do endereço de bloco lógico selecionados por cada registrador no modo LBA. (b) Os campos 
do registrador Seleção de Unidade/Cabeçote. 
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uma vez, evitando uma cara chamada de função na maio¬ 
ria das chamadas, quando o disco está pronto. Nas raras 
ocasiões em que uma espera é necessária, ela então chama 
waitfor , que executa o teste em um laço até que seja verda¬ 
deiro ou até que se passe um limite de tempo predefinido. 
Assim, o valor retornado será verdadeiro com o mínimo 
atraso possível se a controladora estiver pronta, verdadeiro 
depois de um retardo se ela estiver temporariamente indis¬ 
ponível ou falso se ela não estiver pronta depois de esgota¬ 
do o limite de tempo. Teremos mais a dizer sobre o limite 
de tempo ao discutirmos a própria w_waitfor. 

Uma controladora pode tratar mais de uma unidade; 
então, uma vez que se determine que a controladora está 
pronta, um byte é gravado para selecionar a unidade, o 
cabeçote e o modo de operação (linha 10785) e, então, wait¬ 
for é chamada novamente. Às vezes, uma unidade de disco 
não consegue executar um comando ou retornar um códi¬ 
go de erro adequadamente — ela é, afinal de contas, um 
dispositivo mecânico que pode emperrar, enroscar ou que¬ 
brar internamente — e como medida de segurança uma 
mensagem é enviada para a tarefa de relógio agendar uma 
chamada para uma rotina de wakeup. Depois disso, é en¬ 
viado o comando gravando-se primeiro todos os parâme¬ 
tros nos vários registradores e por fim gravando o próprio 
código do comando no registrador de comando. Este últi¬ 
mo passo e a modificação subseqüente das variáveis 
w_command e w_status é uma seção crítica; então, a se- 
qüência inteira é envolvida por chamadas a lock e unlock 
(linhas 10801 a 10805) que desativam e, então, reativam 
as interrupções. 

As próximas funções são curtas. Notamos que w_need_ 
reset (linha 10813) é chamada por wjinish quando a con¬ 
tagem de erros atinge metade de MAX_ERRORS. Ela tam¬ 
bém é chamada quando são atingidos limites de tempo 
enquanto se espera o disco gerar uma interrupção ou tor- 
nar-se pronto. A ação de w_need_reset é simplesmente 
marcar a variável State para cada unidade na matriz wini 
para forçar a inicialização no próximo acesso. 

W_do_close (linha 10828) tem muito pouco a fazer 
para um disco rígido convencional. Quando se acrescentar 
suporte a CD-ROMs ou outros dispositivos removíveis, essa 
rotina terá de ser estendida a fim de gerar um comando 
para destravar a porta ou para ejetar um CD, dependendo 
do que o hardware suporte. 

Com_simple é chamada para enviar comandos de con¬ 
troladora que terminam imediatamente sem uma fase de 
transferência de dados. Comandos que entram nessa cate¬ 
goria incluem os que recuperam a identificação de disco, 
configuram alguns parâmetros e fazem recalibragem. 

Quando com_out chama a tarefa de relógio para pre¬ 
parar um possível salvamento depois de uma falha de uma 
controladora de disco, ele passa o endereço de wjimeout 
(linha 10858) como a função para a tarefa de relógio acor¬ 
dar quando o tempo-limite expirar. Normalmente o disco 
completa a operação requerida e quando o tempo-limite 
ocorre, w_command será encontrado como o valor 
CMDJDLE, o que significa que o disco completou sua ope¬ 


ração e wjimeout, então, pode terminar. Se o comando 
não se completar e a operação for uma leitura ou uma 
gravação, reduzir o tamanho das solicitações de E/S pode 
ajudar. Isso é feito em duas etapas, primeiro reduzindo o 
número máximo de setores que podem ser solicitados para 
8 e depois para 1. Para todos os limites de tempo uma men¬ 
sagem é impressa; w_need_reseté chamada para forçar a 
reinicialização de todas as unidades na próxima tentativa 
de acesso e interrupt é chamada para entregar uma men¬ 
sagem para a tarefa de disco e para simular interrupções 
geradas por hardware que devem ocorrer no final da ope¬ 
ração de disco. 

Quando uma reinicialização é exigida, w_reset (linha 
10889) é chamada. Essa função faz uso de uma função 
fornecida pelo driver de relógio, milli_delay. Depois de um 
retardo inicial para dar tempo para a unidade recuperar-se 
de operações anteriores, um bit no registrador de controle 
da controladora de disco é sinalizado — isto é, ele é trazi¬ 
do para um nível lógico 1 durante um período definido, e 
então, retornado para o nível lógico 0. Seguindo-se a essa 
operação, waitfor é chamada para dar um tempo razoável 
para a unidade sinalizar que está pronta. Caso a reiniciali¬ 
zação não tenha sucesso, uma mensagem é impressa, e 
um código de erro é retornado. Deixa-se o processo que fez 
a chamada decidir o que fazer em seguida. 

Comandos para disco que envolvem transferência de 
dados normalmente terminam gerando uma interrupção, 
que envia uma mensagem de volta à tarefa de disco. De 
fato, uma interrupção é gerada para cada setor lido ou gra¬ 
vado. Assim, depois de enviar esse tipo de comando, 
wjntrjvait (linha 10925) sempre será chamada. Por sua 
vez, wjntrjvait chama receive em um laço, ignorando o 
conteúdo de cada mensagem, esperando uma interrupção 
que configure w_status como não-ocupada. Uma vez re¬ 
cebida essa mensagem, o status da solicitação é verificado. 
Essa é outra seção crítica; então, lock e unlock são utiliza¬ 
dos aqui para garantir que uma nova interrupção não ocor¬ 
rerá e mudará w_status antes de os vários passos envolvi¬ 
dos estarem completos. 

Vimos vários lugares onde a macro waitfor é chamada 
para fazer espera ativa em um bit no registrador de status 
da controladora de disco. Depois do teste inicial, a macro 
waitfor chama wjwaitfor (linha 10955), que chama 
milli_startpam iniciar um temporizador e então entra em 
um laço que alternadamente verifica o registrador de sta¬ 
tus e o temporizador. Se um limite de tempo é atingido, 
w_need_reset é chamada para configurar as coisas para 
uma reinicialização da controladora de disco da próxima 
vez que seus serviços forem solicitados. 

O parâmetro TIMEOUT utilizado por wjvaitfor é defi¬ 
nido na linha 10206 como 32 segundos. Um parâmetro 
semelhante, WAKEUP (linha 10193), utilizado para agen¬ 
dar wakeups da tarefa de relógio, é configurado como 31 
segundos. Esses são períodos de tempo muito longos para 
uma espera ariva, quando se considera que um processo 
comum recebe apenas lOOrns para executar antes de ser 
removido. Mas esses números são baseados no padrão pu- 
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blicado para interfaces de dispositivos de disco com com¬ 
putadores da classe AT, a qual sustenta que até 31 segundos 
devem ser permitidos para um disco entrar em rotação. 0 
fato é que isso, naturalmente, é uma especificação do pior 
cenário e que na maioria dos sistemas o disco entra em 
rotação logo na partida, ou talvez depois de longos perío¬ 
dos de inatividade. 0 mimx ainda está sendo desenvolvido. 
Portanto, é possível que uma nova maneira de tratar limi¬ 
tes de tempo seja indicada quando se acrescentar suporte 
para CD-ROMs (ou outros dispositivos que necessitam ini¬ 
ciar a rotação com freqüência) . 

W_handler (linha 10976) é o manipulador de inter¬ 
rupções. O endereço dessa função é colocado na Tabela de 
Descritores de Interrupções por wjdentify quando a tare¬ 
fa de disco rígido é ativada pela primeira vez. Quando ocorre 
uma interrupção de disco, o registrador de status da con¬ 
troladora de disco é copiado para w_status e então a fun¬ 
ção interrupt no kernel é chamada para reagendar a tare¬ 
fa de disco rígido. Quando isso ocorre, naturalmente, a ta¬ 
refa de disco rígido já está bloqueada como resultado de 
uma chamada a receive ou w_in.tr _wait depois do início 
de uma operação de disco. 

A última função em at_wini.c é w_geometry. Ela re¬ 
toma os valores lógicos máximos de cilindro, cabeçote e 
setor do dispositivo de disco rígido selecionado. Nesse caso, 
os números são reais, não mascarados como foram para o 
driver de disco de RAM. 

3-7.5 Manipulação de Disquete 

O driver de disquete é mais longo e mais complicado 
do que o driver de disco rígido. Isso pode parecer parado¬ 
xal, uma vez que mecanismos de disquete poderiam pare¬ 
cer mais simples do que os de discos rígidos, mas o meca¬ 
nismo mais simples tem uma controladora mais simples 
que requer mais atenção do sistema operacional; e o fato 
de a mídia ser removível adiciona algumas complicações. 
Nesta seção descreveremos algumas coisas que um imple¬ 
mentador precisa considerar ao lidar com disquetes. En¬ 
tretanto, não entraremos nos detalhes do código do driver 
de disquete do MINIX. As partes mais importantes são seme¬ 
lhantes àquelas para o disco rígido. 

Uma das coisas com que não temos de preocupar-nos 
em relação ao driver de disquete é o suporte a múltiplos 
tipos de controladora com que temos de lidar no caso do 
driver de disco rígido. Embora os disquetes de alta densi¬ 
dade atualmente utilizados não fossem suportados no pro¬ 
jeto do IBM PC original, as controladoras de disquete de 
todos os computadores da família IBM PC são suportadas 
por um único driver de software. O contraste com a situa¬ 
ção dos discos rígidos provavelmente se deve à falta de pres¬ 
são para aumentar o desempenho dos disquetes. Os dis¬ 
quetes raramente são utilizados como mídia de armaze¬ 
namento de trabalho durante a operação de um sistema de 
computador; sua velocidade e capacidade de dados tam¬ 
bém são limitadas se comparadas com as de discos rígidos. 


Os disquetes permanecem importantes para distribuição de 
novo software e para backup, assim quase todos os siste¬ 
mas de computador de pequeno porte são equipados com 
pelo menos uma unidade de disquetes. 

O driver de disquete não utiliza SSF ou algoritmo do 
elevador. Ele é estritamente seqüencial, aceitando uma so¬ 
licitação e executando-a antes de aceitar outra solicitação. 
No projeto original do minix foi sentido que, como o mintx 
foi destinado para utilização em computadores pessoais, a 
maioria das vezes haveria somente um processo ativo, e a 
chance de uma solicitação de disco chegar enquanto outra 
estivesse sendo executada era pequena. Assim, haveria pou¬ 
co a ganhar com o aumento considerável na complexida¬ 
de do software que seria necessário para enfileirar solicita¬ 
ções. É até menos vantajoso agora, uma vez que os disque¬ 
tes raramente são utilizados para qualquer coisa além de 
transferência de dados para dentro e para fora de um siste¬ 
ma com um disco rígido. 

Dito isso, mesmo que não haja nenhum suporte no sof¬ 
tware de driver para reorganizar as solicitações, o driver 
de disquete, como qualquer outro driver de bloco, pode tra¬ 
tar uma solicitação de E/S dispersa e, assim, como o driver 
de disco rígido, o driver de disquete coleciona solicitações 
em uma matriz e continua a colecionar essas solicitações, 
contanto que setores seqüenciais sejam solicitados. Entre¬ 
tanto, no caso do driver de disquete, a matriz de solicita¬ 
ções é menor que para o disco rígido, limitada ao número 
máximo de setores por trilha em um disquete. Além disso, 
o driver de disquete presta atenção ao sinalizador 0/770- 
NAL em uma solicitação de E/S dispersa e não prossegue 
para uma nova trilha se as solicitações atuais forem opcio¬ 
nais. 

A simplicidade do hardware de disquete é responsável 
por algumas complicações no software do driver de dis¬ 
quete. Unidades de disquete de baixa capacidade, lentas e 
baratas não justificam as controladoras integradas sofisti¬ 
cadas que são parte dos discos rígidos modernos; então, o 
software do driver precisa negociar explicitamente com 
aspectos de operação de disco que estão ocultos na opera¬ 
ção de um disco rígido. Como um exemplo de uma com¬ 
plicação causada pela simplicidade das unidades de dis¬ 
quete, considere o posicionamento do cabeçote de leitura/ 
gravação sobre uma trilha particular durante uma opera¬ 
ção SEEK. Nenhum disco rígido jamais exigiu que o sof¬ 
tware de driver explicitamente chamasse uma SEEK. Para 
um disco rígido, o cilindro, o cabeçote e a geometria de 
setor visível para o programador podem não corresponder 
à geometria física, e, de fato, a geometria física pode ser 
bem complicada, com mais setores nos cilindros exteriores 
do que nos interiores. Isso, porém, não é visível para o usu¬ 
ário. Discos rígidos podem aceitar Logical Block Addres- 
sing (LBA), endereçando pelo número absoluto de setor no 
disco, como uma alternativa para o endereçamento por ci¬ 
lindro, cabeçote e setor. Mesmo que o endereçamento seja 
feito por cilindro, cabeçote e setor, qualquer geometria que 
não enderece setores inexistentes pode ser utilizada, desde 
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que a controladora integrada no disco calcule para onde 
mover os cabeçotes de leitura/gravação e faça uma opera¬ 
ção de busca quando necessário. 

Para um disquete, entretanto, é necessária programa¬ 
ção explícita de operações seek. No caso de uma SEEK fa¬ 
lhar, é necessário oferecer uma rotina para executar a ope¬ 
ração RECALIBRATK, que força os cabeçotes para o cilindro 
0. Isso torna possível para a controladora avançá-los para 
uma posição desejada de trilha, parando os cabeçotes por 
um número conhecido de vezes. Operações semelhantes 
são necessárias para o disco rígido, naturalmente, mas a 
controladora da unidade trata-os sem orientação detalha¬ 
da do software do driver de dispositivo. 

Algumas características de uma unidade de disquete que 
complicam seu driver são: 

1. Mídia Removível. 

2. Múltiplos Formatos de Disco. 

3. Controle de Motor. 

Algumas controladoras de disco rígido oferecem mídia 
removível, por exemplo, em uma unidade de CD-ROM, mas 
a controladora da unidade geralmente é capaz de tratar 
quaisquer complicações sem muito suporte no software de 
driver de dispositivo. Com um disquete, entretanto, não há 
o suporte interno e ainda é necessário mais. Algumas utili¬ 
zações mais comuns para disquetes — instalar novo sof¬ 
tware ou fazer backup de arquivos — podem exigir troca 
dos discos nas unidades. Isso pode causar problemas se os 
dados que foram destinados a um disquete forem gravados 
em outro disquete. O driver de dispositivo deve fazer o que 
puder para evitar isso, embora isso nem sempre seja possí¬ 
vel, uma vez que nem todo hardware de unidade de dis¬ 
quete permite determinar se a porta de unidade foi aberta 
desde o último acesso. Outro problema que pode ser causa¬ 
do por mídia removível é que um sistema poderá ser sus¬ 
penso se for feita uma tentativa de acessar uma unidade de 
disquete que atualmente não tem nenhum disquete inseri¬ 
do. Isso pode ser resolvido se uma porta aberta puder ser 
detectada, mas como isso nem sempre é possível, alguma 
provisão deve ser feita para um tempo limite, e um retorno 
de erro se uma operação em um disquete não terminar em 
um tempo razoável. 

Mídia removível pode ser substituída por outra mídia, e 
no caso dos disquetes há muitos possíveis formatos dife¬ 
rentes. O hardware do mixix suporta unidades de disco tanto 
de 3,5 pol. como de 5,25 pol. e os disquetes podem ser for¬ 
matados em uma variedade de maneiras para armazenar 
de 360KB a 1,2MB (em um disquete 5,25 pol.) ou 1,44MB 
(em um disquete de 3,5 pol). O MINIX suporta sete forma¬ 
tos diferentes de disquetes. Há duas possíveis soluções para 
0 problema que isso causa e 0 MINIX permite ambas. Uma 
maneira é referir a cada possível formato como uma uni¬ 
dade distinta e oferecer múltiplos dispositivos secundários. 
O MINIX faz isso e no diretório de dispositivos você encon¬ 
trará 14 dispositivos diferentes definidos, variando d e/dev/ 
pcO, um disquete de 5,25 pol. 36 OK na primeira unidade, a 
/dev/PSl, um disquete de 3,5 pol. 1.44M na segunda uni¬ 


dade. Lembrar das combinações diferentes é incômodo, e 
uma segunda alternativa é fornecida. Quando a primeira 
unidade de disquete é endereçada como /dev/fdO, ou a se¬ 
gunda como /dev/fdl, 0 driver de disquete testa 0 disquete 
atualmente na unidade quando é acessado, para determi¬ 
nar 0 formato. Alguns formatos têm mais cilindros e ou¬ 
tros têm mais setores por trilha. A determinação do forma¬ 
to de um disquete é feita tentando-se ler os setores e as tri¬ 
lhas numerados mais altos. Por um processo de elimina¬ 
ção 0 formato pode ser determinado. Isso. naturalmente, 
leva tempo, e um disco com setores defeituosos poderia ser 
mal-identi ficado. 

A complicação final do driver de disquete é 0 controle 
do motor. Os disquetes não podem ser lidos nem gravados 
a menos que estejam girando. Discos rígidos são projeta¬ 
dos para rodar milhares de horas sem se desgastarem, mas 
deixar os motores ligados 0 tempo todo faz com que uma 
unidade de disquetes desgaste-se rapidamente. Se 0 motor 
ainda não estiver ligado quando uma unidade é acessada, 
é necessário dar um comando para acionar a unidade e, 
então, esperar cerca de meio segundo antes de tentar ler ou 
gravar dados. Ligar e desligar os motores é lento: então, 0 
mixix deixa 0 motor de uma unidade ligado por alguns 
segundos depois que uma unidade é utilizada. Se a unida¬ 
de for utilizada novamente dentro desse intervalo, 0 tem¬ 
porizador é estendido para outros poucos segundos. Se a 
unidade não for utilizada neste intervalo, 0 motor é desli¬ 
gado. 

3.8 RELÓGIOS 

Os relógios (também chamados temporizadores) são 
essenciais para a operação de qualquer sistema de compar¬ 
tilhamento de tempo por várias razões. Eles mantêm a hora 
do dia e impedem que um processo monopolize a CPU, 
entre outras coisas. O software do relógio pode assumir a 
forma de um driver de dispositivo, mesmo que um relógio 
não seja um dispositivo de bloco como um disco, ou um 
dispositivo de caractere, como um terminal. Nosso exame 
dos relógios seguirá 0 mesmo padrão das seções anteriores: 
primeiro veremos 0 hardware e 0 software do relógio em 
geral e, então, veremos mais de perto como essas idéias são 
aplicadas no MINIX. 

3.8.1 Hardware do Relógio 

Dois tipos de relógios são comumente utilizados nos 
computadores e ambos são bem diferentes daqueles utili¬ 
zados pelas pessoas. Os relógios mais simples são ligados 
em uma fonte de alimentação de 110 ou de 220 volts e 
causam uma interrupção a cada ciclo de voltagem, a 50 
ou a 60Hz. 

O outro tipo de relógio é construído a partir de três com¬ 
ponentes: um oscilador de cristal, um contador e um regis¬ 
trador de armazenamento, como mostrado na Figura 3- 
23. Quando um pedaço de cristal de quartzo é cortado ade- 
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quadamente e montado sob tensão, pode-se fazê-lo gerar 
um sinal periódico de exatidão muito alta, geralmente no 
alcance de 5 a 100MHz, dependendo do cristal escolhido. 
Pelo menos um circuito desse tipo é normalmente encon¬ 
trado em qualquer computador, oferecendo um sinal de 
sincronização para os vários circuitos do computador. Esse 
sinal alimenta o contador para fazê-lo contar para baixo 
até zero. Quando o contador atinge zero, ele causa uma 
interrupção da CPU. 

Relógios programáveis geralmente têm vários modos 
de operação. No modo one-shot, quando o relógio é ini¬ 
ciado, ele copia o valor do registrador de armazenamento 
no contador e, então, decrementa o contador em cada pul¬ 
so do cristal. Quando o contador atinge zero, ele causa uma 
interrupção e pára até que seja explicitamente iniciado 
novamente pelo software. No modo de onda quadrada, 
depois de atingir zero e causar a interrupção, o registrador 
de armazenamento automaticamente é copiado no conta¬ 
dor, e o processo inteiro é repetido indefinidamente. Essas 
interrupções periódicas são chamadas tiques do relógio. 

A vantagem do relógio programável é que a freqüência 
de suas interrupções pode ser controlada por software. Se 
um cristal de 1MHz é utilizado, então, o contador pulsa a 
cada microssegundo. Com registradores de 16 bits, as in¬ 
terrupções podem ser programadas para ocorrer em inter¬ 
valos de 1 microssegundo a 65,536 milissegundos. Chips 
de relógio programáveis normalmente contêm dois ou três 
relógios independentemente programáveis e também têm 
muitas outras opções (p. ex., contar para cima em vez de 
para baixo, interrupções desativadas e outras). 

Para impedir que o tempo atual seja perdido quando a 
energia do computador é desligada, a maioria dos compu¬ 
tadores tem um relógio de backup alimentado por bateria, 
implementado com o tipo de circuitos de baixo consumo 
utilizado em relógios digitais. O relógio de bateria pode ser 
lido na inicialização. Se o relógio de backup não estiver 
presente, o software pode solicitar ao usuário a data e a 
hora atuais. Há também um protocolo-padrão para um sis¬ 


tema em rede obter o tempo atual de um host remoto. Em 
qualquer caso, o tempo, então, é traduzido no número de 
tiques de relógio desde 12 A.M. Universal Coordinated 
Time (UTC) (antigamente conhecido como Hora Média 
de Greenwich) em I o de janeiro de 1970, como o UNIX e o 
min ix fazem, ou desde alguma outra marca. Em cada ti¬ 
que de relógio, o tempo real é incrementado por uma con¬ 
tagem. Normalmente programas utilitários são oferecidos 
para configurar manualmente o relógio do sistema e o re¬ 
lógio de backup e sincronizar os dois. 

3.8.2 Software do Relógio 

Tudo que o hardware de relógio faz é gerar interrup¬ 
ções a intervalos conhecidos. Tudo mais que envolve tem¬ 
po deve ser feito pelo software, o driver do relógio. Os deve¬ 
res exatos do driver de relógio variam entre sistemas ope¬ 
racionais, mas normalmente incluem a maioria dos se¬ 
guintes: 

1. Manter a hora do dia. 

2. Impedir que processos executem por mais tempo 
do que lhes foi dado. 

3. Contabilizar a utilização da CPU. 

4. Tratar a chamada de sistema aiarm feita por pro¬ 
cessos de usuário. 

5. Oferecer temporizadores watchdog * (“cão de guar¬ 
da”) para partes do próprio sistema. 

6. Traçar perfis, monitorar e reunir estatísticas. 

A primeira função do relógio, manter a hora do dia 
(também chamada de tempo real), não é difícil. Isso exi¬ 
ge apenas incrementar um contador a cada tique de reló¬ 
gio, como mencionado antes. A única coisa a monitorar é 
o número de bits no contador de hora do dia. Com um 
relógio de 60Hz, um contador de 32 bits irá estourar so¬ 
mente após mais de dois anos. Naturalmente o sistema não 
pode armazenar o tempo real como o número de tiques 
desde I o de janeiro de 1970 em 32 bits. 


Oscilador de cristal 



Figura 3-23 Um relógio programável. 


'N. de R. Watchdog Timer: é um circuito acrescentado ao equipamento para gerar uma interrupção quando este não receber um RESET em um 
tempo determinado. Serve para tomar uma atitude no caso da CPU se perder, por exemplo, por motivo de ruído (ou BUG de software). 
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Três abordagens podem ser adotadas para resolver esse 
problema. A primeira é utilizar um contador de 64 bits, 
embora isso torne a manutenção do contador mais cara 
uma vez que tem de ser feita muitas vezes por segundo. A 
segunda é manter o tempo do dia em segundos, em vez de 
em tiques, utilizando um contador subsidiário para contar 
tiques até que um segundo inteiro tenha acumulado. Como 
2 i2 segundos é de mais de 136 anos, esse método funciona¬ 
rá bem até o século XXII. 

A terceira abordagem é contar em tiques, mas fazer isso 
em relação ao tempo em que o sistema é inicializado, em 
vez de relativo a um momento externo fixo. Quando o re¬ 
lógio de backup é lido ou o usuário digita o tempo real, o 
tempo de inicialização de sistema é calculado a partir do 
valor da hora atual do dia e armazenado na memória de 
forma conveniente. Mais tarde, quando a hora do dia for 
solicitada, a hora do dia armazenada é adicionada ao con¬ 
tador para obter a hora atual. Todas as três abordagens são 
mostradas na Figura 3-24. 

A segunda função do relógio é impedir que processos 
executem por muito tempo. Sempre que um processo é ini¬ 
ciado, o agendador deve iniciar um contador para o valor 
do quantum desse processo em tiques de relógio. Em cada 
interrupção de relógio, o driver de relógio decrementa o 
contador do quantum por 1. Quando atinge zero, o tal dri¬ 
ver de relógio chama o agendador para configurar outro 
processo. 

A terceira função do relógio é fazer contabilidade da 
CPU. A maneira mais precisa para tanto é iniciar um se¬ 
gundo temporizador, distinto do temporizador principal do 
sistema, sempre que um processo é iniciado. Quando esse 
processo é parado, o temporizador pode ser lido para infor¬ 
mar por quanto tempo o processo executou. Para fazer as 
coisas corretamente, o segundo temporizador deve ser sal¬ 
vo quando uma interrupção ocorre e restaurado depois. 

Uma maneira menos precisa, mas muito mais simples, 
de fazer a contabilidade é manter um ponteiro para a en¬ 
trada da tabela de processos para o processo atualmente 
em execução em uma variável global. Em cada tique de 
relógio, um campo na entrada do processo atual é incre¬ 
mentado. Assim, cada tique de relógio é contabilizado para 
o processo que executa no momento do tique. Um proble¬ 
ma menor com essa estratégia é que, se muitas interrup¬ 


ções ocorrem durante a execução de um processo, ele é 
ainda cobrado por um tique inteiro, mesmo que não tenha 
feito muito trabalho. Uma contabilidade adequada para a 
CPU durante uma interrupção é muito cara e nunca é fei¬ 
ta. 

No MINTX e em muitos outros sistemas, um processo pode 
solicitar que o sistema operacional forneça-lhe um aviso 
depois de um certo intervalo. 0 aviso é normalmente um 
sinal, uma interrupção, uma mensagem ou algo semelhan¬ 
te. Uma aplicação que exige esse tipo de aviso é uma rede 
em que um pacote não-confirmado dentro de um certo 
intervalo de tempo deve ser retransmitido. Outra aplicação 
é instrução auxiliada por computador, na qual se um alu¬ 
no não oferecer uma resposta dentro de um certo tempo a 
resposta lhe é informada. 

Se o driver de relógio tivesse relógios suficientes, ele 
poderia definir um relógio separado para cada solicitação. 
Não sendo esse o caso, ele deve simular múltiplos relógios 
virtuais com um único relógio físico. Uma maneira de fa¬ 
zer isso é manter uma tabela em que o tempo de sinaliza¬ 
ção para todos os temporizadores pendentes é mantido, 
assim como uma variável que dá o tempo do próximo. Sem¬ 
pre que a hora do dia é atualizada, o driver verifica se o 
próximo sinal ocorreu. Se ocorreu, a próxima ocorrência é 
buscada na tabela. 

Se muitos sinais são esperados, é mais eficiente simu¬ 
lar múltiplos relógios encadeando todas as solicitações de 
relógios pendentes, classificadas segundo a hora, em uma 
lista encadeada, como mostrado na Figura 3-25. Cada en¬ 
trada na lista informa quantos tiques de relógio após o 
anterior devem ser esperados antes de causar um sinal. Neste 
exemplo, os sinais são pendentes para 4203, 4207, 4213, 
4215 e 4216. 

Na Figura 3-25, a próxima interrupção ocorre em três 
tiques. Em cada tique, Próximo sinal é decrementado. 
Quando chega a 0, o sinal correspondente ao primeiro item 
na lista é causado e esse item é removido da lista. Então, 
Próximo sinal é configurado como o valor da entrada agora 
no topo da lista, neste exemplo, 4. 

Note que durante uma interrupção de relógio, o driver 
de relógio tem várias coisas a fazer — incrementar o tem¬ 
po real, decrementar o quantum e verificar para 0, fazer 
contabilidade da CPU e decrementar o contador do alar- 
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Figura 3-24 Três maneiras de manter a hora do dia. 
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Hora atual Próximo sinal 



Figura 3-25 Simulando múltiplos temporizadores com um único relógio. 


me. Entretanto, cada uma dessas operações foi cuidadosa¬ 
mente organizada para ser muito rápida porque precisa 
ser repetida muitas vezes por segundo. 

Partes do sistema operacional também precisam de tem¬ 
porizadores. Esses são chamados temporizadores wa- 
tchdog (“cão de guarda”). Ao estudar o driver de disco 
rígido, vimos que uma chamada de wakeup é agendada 
cada vez que um comando é enviado à controladora de 
disco; então, uma tentativa de recuperação pode ser feita 
se o comando falha completamente. Também menciona¬ 
mos que os drivers de disquete precisam esperar o motor 
do disco atingir uma certa velocidade e devem desligar o 
motor se nenhuma atividade ocorrer em um certo tempo. 
Algumas impressoras com um cabeçote móvel de impres¬ 
são podem imprimirem 120 caracteres/s (8.3ms/caracte- 
re), mas não podem retornar o cabeçote de impressão à 
margem esquerda em 8,3ms, assim o driver de terminal 
deve aguardar depois que um retomo de carro é digitado. 

O mecanismo utilizado pelo driver de relógio para tra¬ 
tar temporizadores watchdog é o mesmo que para sinais de 
usuário. A única diferença é que quando um temporizador 
dispara, em vez de causar um sinal, o driver de relógio 
chama um procedimento fornecido pelo processo chama- 
dor. O procedimento é parte do código do processo chama- 
dor, mas como todos os drivers estão no mesmo espaço de 
endereço, o driver de relógio pode chamá-lo de qualquer 
jeito. 0 procedimento chamado pode fazer o que for neces¬ 
sário, até causar uma interrupção, embora dentro do ker- 
nel interrupções sejam freqüentemente inconvenientes e 
sinais não existam. Essa é a razão pela qual o mecanismo 
watchdog é oferecido. 

A última coisa em nossa lista é traçar perfis. Alguns sis¬ 
temas operacionais oferecem um mecanismo por meio do 
qual um programa de usuário pode fazer o sistema cons¬ 
truir um histograma de seu contador de programa, de modo 
que ele pode ver onde está gastando seu tempo. Quando 
traçar perfis é uma possibilidade, em cada tique o driver 
verifica se o processo atual está tendo seu perfil traçado e, 
se estiver, ele calcula o número bin (um intervalo de ende¬ 
reços) correspondente ao contador de programa atual. En¬ 
tão, ele incrementa esse bin por um. Esse mecanismo tam¬ 
bém pode ser utilizado para traçar um perfil do próprio 
sistema. 


3.8.3 Visão Geral do Driver de 
Relógio no minix 

O driver de relógio do minix está contido no arquivo 
clock.c. A tarefa de relógio aceita estes seis tipos de mensa¬ 
gem, com os parâmetros mostrados: 

1. HARD_INT 

2. GETJJPTIME 

3. GET_TIME 

4. SET_TIME (novo tempo em segundos) 

5. SET_ALARM (número de processo, procedimento 
a chamar, retardo) 

6 . SET_SYN_AL (número de processo, retardo) 

HARD_INTé a mensagem enviada para 0 driver quan¬ 
do uma interrupção de relógio ocorre e há trabalho a fazer, 
como quando um alarme deve ser enviado ou um processo 
executou por muito tempo. 

GETJJPTIME é utilizada para obter 0 tempo em tiques, 
desde a hora de inicialização, GETJTIME retoma 0 tempo 
real atual como 0 número de segundos passados desde as 
12h de l°de janeiro de 1970, eSETJTIME configura 0 tem¬ 
po real. Ele somente pode ser chamado pelo superusuário. 

Interno ao driver de relógio, o tempo é monitorado uti- 
lizando-se 0 método da Figura 3.24 (c). Quando 0 tempo é 
configurado, 0 driver calcula quando 0 sistema foi inicia- 
lizado. Ele pode fazer essa computação porque tem 0 tem¬ 
po real atual e também sabe por quantos tiques 0 sistema 
executou. 0 sistema armazena 0 tempo real da inicializa¬ 
ção em uma variável. Mais tarde, quando GETJTIME é cha¬ 
mada, ela converte 0 valor atual do contador de tique para 
segundos e adiciona ao tempo da inicialização armazena¬ 
do. 

SET_ALARM permite que um processo configure um 
temporizador que dispara em um número especificado de 
tiques de relógio. Quando um processo de usuário faz uma 
chamada aiarm, ele envia uma mensagem para 0 gerenci¬ 
ador de memória, que, então, envia essa mensagem para 0 
driver de relógio. Quando 0 alarme dispara, 0 driver de 
relógio envia uma mensagem para 0 gerenciador de me¬ 
mória, que, então, cuida de fazer 0 sinal acontecer. 

SETJAIARM também é utilizada por tarefas que preci¬ 
sam iniciar um temporizador watchdog. Quando 0 tempo- 
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rizador dispara, o procedimento fornecido simplesmente é 
chamado. O driver de relógio não tem nenhum conheci¬ 
mento do que o procedimento faz. 

SETJPt'N_AL é semelhante a SET_ALARM. mas é utili¬ 
zada por um alarme síncrono. Um alarme síncrono en¬ 
via uma mensagem para um processo, em vez de gerar um 
sinal ou chamar um procedimento. A tarefa do alarme sín¬ 
crono envolve despachar mensagens para os processos que 
as solicitam. Alarmes síncronos serão discutidos detalha¬ 
damente mais tarde. 

A tarefa de relógio não utiliza nenhuma estrutura de 
dados importante, mas há diversas variáveis utilizadas para 
monitorar o tempo. Somente uma é uma variável global, 
lostjicks, definida em glo.h (linha 5031). Essa variável e' 
fornecida para ser utilizada por qualquer driver que possa 
ser adicionado ao MiNix no futuro e que talvez desative as 
interrupções por um tempo suficientemente longo que um 
ou mais tiques de relógio possam ser perdidos. Atualmente 
ela não é utilizada, mas se um driver desse tipo fosse escri¬ 
to o programador poderia fazer com que lostjicks fosse 
incrementado para compensar o tempo durante o qual as 
interrupções de relógio foram inibidas. 

Obviamente, as interrupções de relógio ocorrem muito 
freqüentemente e seu rápido tratamento é importante. O 
MiNix consegue isso fazendo uma quantidade mínima de 
processamento na maioria das interrupções de relógio. Ao 
receber uma interrupção, o manipulador configura uma 
variável local, ticks, como lostjicks + 1 e, então, utiliza 
essa quantidade para atualizar os tempos de contabilidade 
e pendingjicks (linha 11079) e redefine lostjicks para 
zero. Pendingjicks é uma variável PRNATE, declarada fora 
de todas as definições de função, mas conhecida apenas 
pelas funções definidas em clock.c. Outra variável PRIVA- 
TE, schedjicks, é decrementada em cada tique para acom¬ 
panhar o tempo de execução. O manipulador de interrup¬ 
ções envia uma mensagem à tarefa de relógio somente se 
um alarme está vencido ou um quantum de execução foi 
utilizado. Esse esquema resulta no manipulador de inter¬ 
rupções, retornando quase imediatamente na maioria das 
interrupções. 

Quando a tarefa de relógio recebe qualquer mensagem, 
ela adiciona pendingjicks à variável realtime (linha 
11067) e, então, zera pendingjicks. Realtime , junto com 
a variável bootjime (linha 11068 ), permite que a hora 
atual do dia seja calculada. Ambas são variáveis PRMTE\ 
então, a única maneira de qualquer outra parte do sistema 
obter 0 tempo é enviando uma mensagem à tarefa de reló¬ 
gio. Embora em qualquer instante realtime possa estar in¬ 
correto, esse mecanismo assegura que ele seja sempre exa¬ 
to quando necessário. Se seu relógio está correto quando 
você 0 vê, importa se ele está incorreto quando você não 
está olhando? 

Para manipular alarmes, next_alarm registra 0 tem¬ 
po em que 0 próximo sinal ou chamada de watchdog pode 
acontecer. O driver precisa ser cuidadoso aqui, porque 0 
processo que solicita 0 sinal pode sair ou pode ser elimina¬ 
do antes de 0 sinal acontecer. Quando é hora do sinal, uma 


verificação é feita para ver se ainda é necessário. Se não for 
necessário, não será executado. 

A cada processo de usuário permite-se apenas um tem¬ 
porizador. Executar uma chamada alarm enquanto 0 tem¬ 
porizador ainda está executando cancela 0 primeiro tem¬ 
porizador. Portanto, uma maneira conveniente de arma¬ 
zenar os temporizadores é reservar uma palavra na entra¬ 
da da tabela de processos para 0 temporizador de cada pro¬ 
cesso, se houver um. Para tarefas, a função a ser chamada 
também deve ser armazenada em algum lugar; então, uma 
matriz, watcb_dog, foi oferecida para essa finalidade. Uma 
matriz semelhante, synjable, armazena ainalizadores 
para indicar a cada processo se ele deve obter um alarme 
síncrono. 

A lógica geral do driver de relógio segue 0 mesmo pa¬ 
drão dos drivers de disco. O programa principal é um laço 
sem fim que recebe mensagens, despacha de acordo com 0 
tipo de mensagem e, então, envia uma resposta (exceto 
para CLOCKJTICK). Cada tipo de mensagem é tratado por 
um procedimento separado, seguindo nossa convenção de 
atribuir nomes a todos os procedimentos chamados a par¬ 
tir do laço principal como do_. rxv, onde xv.v é diferente 
para cada um, naturalmente. A propósito, muitos linkedí- 
tors , infelizmente, truncam nomes de procedimento para 
sete ou para oito caracteres; assim, os nomes do_setJime 
e do_set_alarm estão potencialmente em conflito. O últi¬ 
mo foi renomeado para do_setalarm . Esse problema ocor¬ 
re em todo 0 MINIX e normalmente é resolvido quebrando- 
se alguns nomes. 

A Tarefa de Alarme Síncrono 

Há uma segunda tarefa a ser discutida nesta seção, a 
tarefa de alarme síncrono. Um alarme síncrono é seme¬ 
lhante a um alarme, mas em vez de enviar um sinal para 
chamar uma função watchdog quando 0 período de tempo 
limite expira, a tarefa de alarme síncrono envia uma men¬ 
sagem. Um sinal pode chegar ou uma tarefa watchdog pode 
ser chamada sem qualquer relação com que parte de uma 
tarefa está executando, portanto, alarmes desse tipo são as¬ 
síncronos. Em contraposição, uma mensagem é recebida 
somente quando 0 receptor executou uma chamada recei- 
ve. 

O mecanismo de alarme síncrono foi adicionado ao 
MINIX para suportar 0 servidor de rede, que, como 0 geren¬ 
ciador de memória e 0 servidor de arquivos, executa como 
um processo separado. Com freqüência, precisa-se de um 
limite no tempo em que um processo pode ser bloqueado 
enquanto espera por entradas. Por exemplo, em uma rede, 
a falha em obter a confirmação de um pacote de dados 
dentro de um período definido é provavelmente devida a 
uma falha de transmissão. Um servidor de rede pode confi¬ 
gurar um alarme síncrono antes de tentar receber uma 
mensagem e bloquear. Como 0 alarme síncrono é entregue 
como uma mensagem, ele acabará desbloqueando 0 servi¬ 
dor se nenhuma mensagem for recebida da rede. Ao obter 
qualquer mensagem, 0 servidor deve primeiro redefinir 0 
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alarme. Então, examinando o tipo ou a origem da mensa¬ 
gem, ele pode determinar se um pacote chegou ou se foi 
desbloqueado por um tempo limite. Se for o último caso, o 
servidor pode tentar uma recuperação, normalmente re¬ 
enviando o último pacote não-confirmado. 

Um alarme síncrono é mais rápido que um alarme en¬ 
viado utilizando um sinal, que exige várias mensagens e 
uma quantidade considerável de processamento. Uma fun¬ 
ção de watchdog é rápida, mas é útil somente para tarefas 
compiladas no mesmo espaço de endereço que a tarefa de 
relógio. Quando um processo está esperando uma mensa¬ 
gem, um alarme síncrono é mais apropriado e mais sim¬ 
ples que sinais ou funções watchdog e facilmente é tratado 
com um pequeno processamento adicional. 

O Manipulador de Interrupções do 
Relógio 

Como descrito anteriormente, quando uma interrup¬ 
ção de relógio ocorre, realtime não é atualizado imediata¬ 
mente. A rotina de serviço de interrupção mantém o conta- 
dor pmdingjicks e faz trabalhos simples como contabili¬ 
zar o tique atual para um processo e decrementar o tempo¬ 
rizador do quantum. Uma mensagem é enviada para a ta¬ 
refa de relógio somente quando trabalhos mais complica¬ 
dos devem ser feitos. Isso é algo de acordo com o ideal do 
MINIX de as tarefas comunicarem-se totalmente por men¬ 
sagens, mas também é uma concessão à realidade de que 
servir tiques de relógio consome tempo de CPU. Estimou- 
se que em uma máquina lenta fazer isso dessa maneira 
resulta em um aumento de 15% na velocidade do sistema 
em relação a uma implementação que envia uma mensa¬ 
gem à tarefa de relógio em cada interrupção de relógio. 

Sincronização em Milissegundos 

Como outra concessão à realidade, são apresentadas em 
clock.c algumas rotinas que oferecem precisão de milisse¬ 
gundos. Retardos de até um milissegundo são necessários 
para vários dispositivos de E/S. Não há maneira prática de 
fazer isso utilizando alarmes e a interface de passagem de 
mensagens. As funções aqui destinam-se a serem chama¬ 
das diretamente pelas tarefas. A técnica utilizada é a mais 
antiga e simples técnica de E/S: acesso direto. 0 contador 
que é utilizado para gerar a interrupção de relógio é lido 
diretamente, o mais rápido possível, e a contagem é con¬ 
vertida em milissegundos. 0 chamador faz isso repetida¬ 
mente até que o tempo desejado tenha passado. 

Resumo dos Serviços de Relógio 

A Figura 3-26 resume os vários serviços fornecidos por 
clock.c. Há várias maneiras de acessar o relógio e várias 
maneiras de as solicitações serem atendidas. Alguns servi¬ 
ços estão disponíveis para qualquer processo, e os resulta¬ 
dos são retomados em uma mensagem. 


0 tempo de funcionamento pode ser obtido por uma 
chamada de função a partir do kernel ou por uma tarefa 
para evitar o overhead de uma mensagem. Um alarme pode 
ser solicitado por um processo de usuário, sendo o resulta¬ 
do final disso um sinal ou. para uma tarefa, a ativação de 
uma função watchdog. Nenhum desses mecanismos pode 
ser utilizado por um processo de servidor, mas um servidor 
pode solicitar um alarme síncrono. Uma tarefa ou o kernel 
pode solicitar um retardo que utiliza a função milli_delav 
ou pode incorporar chamadas para milli jelapsed em uma 
rotina de acesso direto, por exemplo, enquanto espera a 
entrada de uma porta. 

3.8.4 Implementação do Driver de 
Relógio no MINIX 

Quando o mintx inicia, todos os drivers são chamados. 
A maioria deles apenas tenta obter uma mensagem e blo¬ 
queia. 0 driver de relógio, clockjask (linha 11098 ), tam¬ 
bém faz isso, mas primeiro chama initjdock para inicia- 
lizar a freqüência programável do relógio para 60Hz. Quan¬ 
do qualquer mensagem é recebida, ele adiciona pending_ 
ticks a realtime e, então, zera pendingjicks antes de fazer 
qualquer outra coisa. Essa operação potencialmente pode¬ 
ria entrar em conflito com uma interrupção de relógio; 
assim chamadas lock e unlock são utilizadas para preve¬ 
nir uma condição de corrida (linhas 11115 a 11118). De 
resto, o laço principal do driver de relógio é essencialmen¬ 
te o mesmo que os outros drivers: uma mensagem é rece¬ 
bida, uma função que realiza o trabalho solicitado é cha¬ 
mada, e uma mensagem de resposta é enviada. 

Dojdocktick (linha 11140) não é chamada em cada 
tique do relógio; então, seu nome não é uma descrição exata 
de sua função. Ela é chamada quando o manipulador de 
interrupções determinou que pode haver algo importante 
a fazer. Primeiro, uma verificação é feita para ver se um 
temporizador de sinal ou o watchdog disparou. Se isso acon¬ 
teceu, todas as entradas de alarme na tabela de processos 
são inspecionadas. Como os tiques não são processados 
individualmente, vários alarmes podem disparar em uma 
passagem pela tabela. Também é possível que o processo 
que deveria obter o próximo alarme já tenha encerrado. 
Quando é localizado um processo cujo alarme é menor que 
o tempo atual, mas não zero, a entrada da matriz 
watch_dog correspondente a tal processo é verificada. Na 
linguagem de programação C, um valor numérico tam¬ 
bém tem um valor lógico, assim o teste na linha 11 l6l 
retorna TRUE se um endereço válido estiver armazenado 
na entrada em watch_dog e a função correspondente é 
chamada indiretamente na linha 11163. Se um ponteiro 
nulo for encontrado (representado em C pelo valor zero), 
o teste é avaliado como FALSE e cause_sig é chamada para 
enviar um sinal SIGALRM. A entrada em watch_dog tam¬ 
bém é utilizada quando um alarme síncrono é necessário. 
Nesse caso, o endereço armazenado é o endereço de 
cause_alarm, em vez de o endereço de uma função wa- 
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Figura 3-26 0 código de relógio suporta diversos serviços relacionados com tempo. 


tchdog pertencente a uma tarefa em particular. Para envi¬ 
ar um sinal, poderíamos ter armazenado o endereço de 
cause_sig, mas, então, precisaríamos ter escrito cause_sig 
de maneira diferente, para não esperar nenhum argumen¬ 
to e obter o número do processo de destino de uma variável 
global. Alternativamente, poderíamos ter exigido que to¬ 
dos os processos watchdog esperassem um argumento que 
eles não precisam. 

Discutiremos cause_sig quando tratarmos da tarefa de 
sistema em uma seção adiante. Seu trabalho é enviar uma 
mensagem para o gerenciador de memória. Isto requer uma 
verificação de se o gerenciador de memória atualmente está 
esperando uma mensagem. Em caso afirmativo, envia uma 
mensagem informando sobre o alarme. Se o gerenciador 
de memória está ocupado, uma nota é feita para informá- 
lo na primeira oportunidade. 

Ao fazer o laço pela tabela de processos inspecionando 
o valor de pjilarm para cada processo, next_alarm é atu¬ 
alizado. Antes de iniciar o laço é configurado para um nú¬ 
mero muito grande (linha 11151) e, então, para cada pro¬ 
cesso cujo valor do alarme é diferente de zero depois de 
enviar alarmes ou sinais, uma comparação é feita entre o 
alarme do processo e next_alarm, o qual é configurado 
para o menor valor (linhas 11171 e 11172). 

Depois de processar alarmes, dojdocktick prossegue 
para ver se é hora de agendar outro processo. 0 quantum 
de execução é mantido na variável PRNATE schedjicks, 
que normalmente é decrementada pelo manipulador de 
interrupções de relógio em cada tique de relógio. Entretan¬ 
to, nesses tiques, quando dojdocktick é ativado, não é de¬ 
crementada pelo manipulador, permitindo que o próprio 
dojdocktick faça isso e teste quanto a um resultado zero 
na linha 11178. Schedjicks não é redefinida sempre que 
um novo processo é agendado (porque o sistema de arqui¬ 
vos e o gerenciador de memória têm permissão para exe¬ 
cutar até sua conclusão). Em vez disso, ela é redefinida 
depois de cada SCHED_RATE tiques. A comparação na li¬ 
nha 11179 é para assegurar que o processo atual realmen¬ 
te executou pelo menos um tique completo do agendador 
antes de tomar a CPU dele. 


0 próximo procedimento, do_getuptime (linha 11189), 
é somente uma linha; ele coloca o valor atual de realtime 
(o número de tiques desde a inicialização) no campo ade¬ 
quado na mensagem a ser retornada. Qualquer processo 
pode obter o tempo passado dessa maneira, mas o overhe- 
ad da mensagem é um preço alto a exigir das tarefas, por¬ 
tanto, é oferecida uma função relacionada, getjiptime (li¬ 
nha 11200), que pode ser chamada diretamente pelas ta¬ 
refas. Como não é chamada via uma mensagem à tarefa 
de relógio, ela mesma precisa adicionar os tiques penden¬ 
tes ao realtime atual. Lock e unlock são necessários aqui 
para impedir que uma interrupção de relógio ocorra en- 
quanto pendingjicks está sendo acessado. 

Para obter o tempo real atual, do_getJime (linha 
11219 ) calcula o tempo real atual a partir de realtime e 
bootjime (o tempo de inicialização do sistema em segun¬ 
dos) . Do_setJime (linha 11230) é seu complemento. Ele 
calcula um novo valor para bootjime com base no tempo 
real atual dado e no número de tiques desde a inicializa¬ 
ção. 

Os procedimentos do_setalarm (linha 11242) e 
do_setsynjzlrm (linha 11269) são tão semelhantes que 
os discutiremos juntos. Ambos extraem os parâmetros que 
especificam o processo a ser sinalizado e o tempo de espera 
da mensagem. Dojetalarm também extrai uma função 
a chamar (linha 11257), embora algumas linhas mais 
adiante substituam esse valor por um ponteiro nulo se o 
processo de destino for um processo de usuário e não uma 
tarefa. Já vimos como esse ponteiro é mais tarde testado em 
dojdocktick para determinar se o destino deve obter um 
sinal ou uma chamada para um watchdog. O tempo res¬ 
tante para o alarme (em segundos) também é calculado 
pelas duas funções e configurado na mensagem de retor¬ 
no. Ambos, então, chamam common_setalarm para en¬ 
cerrar. No caso da chamada do_setsyn_alarm, o parâme¬ 
tro de função passado para common jetalarm é sempre 
cause_alarm. 

Commom jetalarm (linha 11291) termina o traba¬ 
lho iniciado por qualquer uma das duas funções que aca¬ 
bamos de discutir. Então, ela armazena a hora do alarme 
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na tabela de processos e o ponteiro para o procedimento 
watchdog (que também pode ser um ponteiro para 
cause_alarm ou um ponteiro nulo) na matriz watch_dog. 
Então, ele varre a tabela de processos inteira para encon¬ 
trar o próximo alarme, assim como é feito por do_clocktick. 

Cause_alarm (linha 11318) é simples; ele define como 
TRUE uma entrada na matriz synjable correspondente 
ao destino do alarme síncrono. Se a tarefa de alarme sín¬ 
crono não estiver ativa, é enviada uma mensagem para 
acordá-la. 

Implementação da Tarefa de Alarme 
Síncrono 

A tarefa de alarme síncrono, syn_alarm_task (linha 
11333), segue o modelo básico de todas as tarefas. Inicia e, 
então, entra em um laço interminável em que recebe e en¬ 
via mensagens. A inicialização consiste em declarar-se viva 
configurando a variável syn_al_alive como TRUE e, en¬ 
tão, declarando que não tem nada a fazer colocando todas 
as entradas em synjable como FALSE. Há uma entrada 
em synjable para cada entrada na tabela de processos. 
Ela começa seu laço externo declarando concluído seu tra¬ 
balho e, então, entra em um laço interno onde verifica to¬ 
das as entradas em synjable. Se localiza uma entrada que 
indica que um alarme síncrono é esperado, ela redefine a 
entrada, envia uma mensagem do tipo CLOCKJNT para o 
processo apropriado e declara seu trabalho não-concluído. 
Na parte inferior do seu laço externo, ela não faz pausa 
para esperar qualquer nova mensagem a menos que seu 
sinalizador work_done seja configurado. Uma nova men¬ 
sagem não é necessária para informar que há mais traba¬ 
lho a fazer, uma vez que cause_alarm escreve diretamen¬ 
te em synjable. Uma mensagem é necessária somente 
para acordá-la depois que ela executar todo o trabalho. 0 
efeito é que ela faz um ciclo muito rapidamente, contanto 
que haja alarmes a serem entregues. 

De fato, essa tarefa não é utilizada pela versão de distri¬ 
buição do MlNix. Entretanto, se você compilar o minix adi¬ 
cionando suporte de rede, ela será utilizada pelo servidor 
de rede, o qual precisa exatamente desse tipo de mecanis¬ 
mo para impor limites de tempo rápidos se pacotes não 
forem recebidos quando esperados. Além da necessidade 
de velocidade, não se pode enviar um sinal a um servidor, 
uma vez que os servidores devem executar eternamente, e 
a ação-padrão da maioria dos sinais é eliminar o processo 
de destino. 

A Implementação do Manipulador de 
Interrupções de Relógio 

0 projeto do manipulador de interrupções de relógio é 
um compromisso entre fazer muito pouco (assim o tempo 
de processamento será minimizado) e fazer o suficiente 
para tornar infreqüentes as caras ativações da tarefa de re¬ 
lógio. Ele muda algumas variáveis e testa algumas outras. 
Clockjjandler (linha 11374) inicia fazendo a contabili¬ 


dade do sistema. 0 minix monitora tanto o tempo do usuá¬ 
rio como o do sistema. O tempo do usuário é cobrado de 
um processo se ele estiver executando quando ocorre um 
tique do relógio. 0 tempo de sistema é cobrado se o sistema 
de arquivos ou o gerenciador de memória estiver execu¬ 
tando. A variável bill J>tr sempre aponta para o último pro¬ 
cesso de usuário agendado (os dois servidores não contam). 
A cobrança é feita nas linhas 11447 e 11448. Depois que a 
cobrança termina, a variável mais importante mantida por 
clockjjandler , pendingjicks , é incrementada (linha 
11450). O tempo real deve ser conhecido para testar se 
clockjjandler deve acordar//}' ou enviar uma mensagem 
à tarefa de relógio; porém, realmente atualizar o próprio 
realtime é caro, porque essa operação deve ser feita utili¬ 
zando bloqueios. Para evitar isso, o manipulador calcula 
sua própria versão do tempo real na variável local note. Há 
uma pequena chance de que o resultado seja incorreto de 
vez em quando, mas as consequências de tal erro não seri¬ 
am sérias. 

O restante do trabalho do manipulador depende de vá¬ 
rios testes. O terminal e a impressora precisam ser acorda¬ 
dos de vez em quando. Ttyjimeout é uma variável global, 
mantida pela tarefa de terminal, que armazena o valor de 
quando tty deve ser acordada. Para a impressora, diversas 
variáveis que são PRNATE dentro do módulo da impresso¬ 
ra precisam ser verificadas e testadas na chamada a 
pr_restart, o qual retoma rapidamente mesmo no pior caso 
de a impressora estar desligada. Nas linhas 11455 a 11458, 
é feito um teste que ativa a tarefa de relógio se um alarme 
estiver vencido ou se é tempo de agendar outra tarefa. O 
último teste é complexo, um AND lógico de três testes mais 
simples. O código 

interrupt(CLOCK); 

na linha 11459 resulta em uma mensagem HARDJNTpam 
a tarefa de relógio. 

Ao discutir dojlocktick, notamos que ela decrementa 
schedjicks e testa quanto a zero para ver se o quantum de 
execução expirou. Testar s e schedjicks é igual a um é par¬ 
te do teste complexo que mencionamos acima; se a tarefa 
de relógio não é ativada, ainda é necessário decrementar 
schedjicks dentro do manipulador de interrupções e, se 
atingir zero, redefinir o quantum. Se isso ocorrer, é hora 
também de anotar que o processo atual estava ativo no iní¬ 
cio do novo quantum; isso é feito pela alocação do valor 
atual de bill Jtr para prev_ptr na linha 11466. 

Os Utilitários de Tempo 

Por fim, clock.cc ontêm algumas funções que oferecem 
vários tipos de suporte. Muitas dessas funções são específi¬ 
cas do hardware e precisarão ser substituídas ao portar o 
MINIX para hardware não-Intel. Descreveremos apenas a 
função dessas, sem entrar em seus detalhes internos. 

Initjclock (linha 11474) é chamada pela tarefa do tem¬ 
porizador quando executa pela primeira vez. Ela configu¬ 
ra o modo e o retardo de tempo do chip do temporizador 
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para produzir interrupções de tique de relógio 60 vezes por 
segundo. Apesar do fato de que a “velocidade de CPU" que 
se vê em anúncios para PCs aumentou de 4.77MHz no IBM 
PC original para mais de 200MHz nos sistemas modernos, 
a constante TIMERJJOUNT, utilizada para iniciar o tem¬ 
porizador, é a mesma independente do modelo de PC em 
que o MINIX está executando. Todo PC compatível com IBM, 
independentemente da rapidez com que seu processador 
trabalha, oferece um sinal de 14,3MHz para utilização por 
vários dispositivos que precisam de uma referência de tem¬ 
po. As linhas seriais de comunicações e a exibição de vídeo 
também precisam dessa referência de sincronização. 

0 complemento de init_clock é clock_stop (linha 
11489). Não é realmente necessário, mas é um concessão 
ao fato de que os usuários do MINIX podem querer iniciar 
outro sistema operacional às vezes. Ele simplesmente re¬ 
define os parâmetros do chip do temporizador para o modo- 
padrão de operação que o MS-DOS e outros sistemas opera¬ 
cionais podem esperar o ROM BIOS oferecer quando eles 
iniciam pela primeira vez. 

Milli_delay (linha 11502) é oferecido para utilização 
por qualquer tarefa que precisa de retardos muito curtos. 
Ela é escrita em C sem quaisquer referências específicas de 
hardware, mas utiliza uma técnica que talvez se espere 
encontrar somente em uma rotina de baixo nível de lin¬ 
guagem assembly. Ela inicia um contador em zero e, en¬ 
tão, rapidamente o consulta continuamente até que um 
valor desejado seja alcançado. No Capítulo 2, dissemos que 
essa técnica de espera ativa deveria, em geral, ser evitada, 
mas as necessidades da implementação podem exigir ex¬ 
ceções às regras gerais. A inicialização do contador é feita 
pela próxima função, milli_start (linha 11516), que sim¬ 
plesmente zera duas variáveis. A consulta é feita chaman¬ 
do a última função, millí_elapsed (linha 11529), que aces¬ 
sa o hardware do temporizador. O contador que é exami¬ 
nado é o mesmo utilizado para contar para baixo tiques de 
relógio e pode sofrer underjlow * e ser redefinido para seu 
valor máximo antes de o retardo desejado estar completo. 
Mílli_elapsed corrige isso. 


3.9 TERMINAIS 

Cada computador de propósito geral tem um ou mais 
terminais utilizados para comunicar-se com ele. Os termi¬ 
nais são apresentados em um número extremamente gran¬ 
de de formas diferentes. Cabe ao driver de terminal escon¬ 
der todas essas diferenças, de modo que a parte indepen¬ 
dente de dispositivo do sistema operacional e os programas 
de usuário não precisem ser escritos para cada tipo de ter¬ 
minal. Nas próximas seções, seguiremos nossa abordagem- 


'N. de R. Na linguagem C não há verificação de limite nas operações 
aritméticas; logo quando se subtrai 1 de uma variável inteira com valor 
zero ela passa a representar o valor máximo da faixa de representação 
de seu tipo. Isso caracteriza um underjlow ou “estouro” inferior da 
faixa de representação. 


padrão de primeiro discutir o hardware e o software termi¬ 
nal em geral e, então, discutir o software do MINIX. 

3-9.1 Hardware de Terminal 

Do ponto de vista do sistema operacional, os terminais 
podem ser divididos em três categorias amplas baseadas 
em como 0 sistema operacional comunica-se com eles. A 
primeira categoria consiste em terminais mapeados em 
memória, que se compõem de um teclado e de um disposi¬ 
tivo de exibição, ambos conectados como parte do hardwa¬ 
re do computador. A segunda categoria são terminais que 
interfaceiam via uma linha comunicação serial utilizan¬ 
do 0 RS-232 padrão, freqüentemente por meio de um mo¬ 
dem. A terceira categoria consiste em terminais que são 
conectados ao computador via uma rede. Essa taxonomia 
é mostrada na Figura 3-27. 

Terminais Mapeados em Memória 

A primeira categoria ampla de terminais mostrada na 
Figura 3-27 compõe-se de terminais mapeados em memó¬ 
ria, que são parte integrante dos próprios computadores. 
Os terminais mapeados em memória são interfaceados via 
uma memória especial chamada RAM de vídeo, que for¬ 
ma parte do espaço de endereçamento do computador e é 
endereçada pela CPU da mesma maneira que 0 restante da 
memória (ver a Figura 3-28). 

Também na placa de RAM de vídeo está um chip cha¬ 
mado controladora de vídeo. Esse chip puxa códigos de 
caractere da RAM de vídeo e gera 0 sinal utilizado para 
orientar 0 monitor. O monitor gera um feixe de elétrons 
que varre a tela horizontalmente, pintando linhas nele. 
Geralmente a tela tem 480 a 1024 linhas de cima para bai¬ 
xo, com 640 a 1.200 pontos por linha. Esses pontos são 
chamados pixels. O sinal da controladora de vídeo mo¬ 
dula 0 feixe de elétrons, determinando se um dado pixel 
será claro ou escuro. Os monitores coloridos têm três fei¬ 
xes, para vermelho, verde e azul, que são independente¬ 
mente modulados. 

Um dispositivo de exibição monocromática simples pode 
ajustar cada caractere em uma caixa de 9 pixels de largura 
por 14 pixels de altura (incluindo 0 espaço entre caracte¬ 
res) e tem 25 linhas de 80 caracteres. A tela, então, teria 
350 linhas de varredura com 720 pixels cada uma. Cada 
um desses quadros é redesenhando 45 a 70 vezes por se¬ 
gundo. A controladora de vídeo poderia ser projetada para 
buscar os primeiros 80 caracteres da RAM de vídeo, gerar 
14 linhas de varredura, buscar os próximos 80 da RAM de 
vídeo, gerar as 14 linhas de varredura seguintes e assim 
por diante. De fato, a maioria busca cada caractere uma 
vez por linha de varredura para eliminar a necessidade de 
buffers na controladora. Os padrões de 9 por 14 bits para os 
caracteres são mantidos em uma ROM utilizada pela con¬ 
troladora de vídeo. (A RAM também pode ser utilizada para 
suportar fontes personalizadas.) A ROM é endereçada por 
um endereço de 12 bits; 8 bits do código de caractere e 4 
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Figura 3-27 Tipos de terminal. 


bits especificam uma linha de varredura. Os 8 bits em cada 
byte da ROM controlam 8 pixels; o f pixel entre caracteres 
está sempre em branco. Portanto, 14 x 80 = 1120 referên¬ 
cias de memória à RAM de vídeo são necessárias por linha 
de texto na tela. O mesmo número de referências é feito 
para a ROM do gerador de caracteres. 

O IBM PC tem vários modos para a tela. No mais sim¬ 
ples, ele utiliza um vídeo mapeado por caracteres para o 
console. Na Figura 3-29(a) vemos uma parte da RAM de 
vídeo. Cada caractere na tela da Figura 3-29(b) ocupa dois 
caracteres na RAM. O caractere de ordem inferior é o códi¬ 
go ASCII para o caractere a ser exibido. O caractere de or¬ 
dem superior é o byte de atributo, que é utilizado para es¬ 
pecificar a cor, o vídeo reverso, a intermitência e assim por 
diante. A tela completa de 25 por 80 caracteres requer 4.000 
bytes de RAM de vídeo neste modo. 

Os terminais de mapa de bits utilizam o mesmo princí¬ 
pio, exceto que cada pixel na tela é controlado individual¬ 
mente. Na configuração mais simples, para um vídeo mo¬ 
nocromático, cadapixel tem um bit correspondente na RAM 
de vídeo. No outro extremo, cada pixel é representado por 
um número de 24 bits, com 8 bits para cada vermelho, 
verde e azul. Um vídeo colorido de 768 x 1024 com 24 bits 


por pixel requer 2MB de RAM apenas para armazenar a 
imagem. 

Com um vídeo mapeado em memória, o teclado está 
completamente separado da tela. Ele pode ser interfaceado 
via uma porta serial ou paralela. Em cada ação de teclado, 
a CPU é interrompida, e o driver de teclado extrai o carac¬ 
tere digitado lendo uma porta de E/S. 

No IBM PC, o teclado contém um microprocessador 
embutido que se comunica por meio de uma porta serial 
especializada com um chip de controladora na placa-mãe. 
Uma interrupção é gerada sempre que uma tecla é pressio¬ 
nada e também quando uma tecla é liberada. Além disso, 
tudo que o hardware de teclado oferece é o número da te¬ 
cla, não o código ASCII. Quando a teclad é pressionada, o 
código da tecla (30) é colocado em um registrador de E/S. 
Cabe ao driver determinar se é caixa baixa (minúscula), 
caixa alta (maiúscula), CTRL-A, ALT-A, CTRL-ALT-A ou al¬ 
guma outra combinação. Como o driver pode informar 
quais teclas foram pressionadas, mas ainda não liberadas 
(p. ex., shift), ele tem informações suficientes para fazer o 
trabalho. Embora essa interface de teclado coloque todo o 
peso sobre o software, ela é extremamente flexível. Por 
exemplo, programas de usuário podem interessar-se se um 


Barramento 


Placa de RAM Monitor 



Porta paralela Teclado 


Figura 3-28 Terminais de memória mapeada gravam diretamente na RAM de vídeo. 
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Figura 3-29 (a) Uma imagem de RAM de vídeo para o monitor monocromático IBM. (b) A tela 

correspondente. Os xs são bytes de atributo. 


algarismo recém-digitado veio da fila superior de teclas ou 
do teclado numérico. A princípio, o driver pode oferecer 
essas informações. 

Terminais RS-232 

Terminais RS-232 são dispositivos que contêm um te¬ 
clado e um monitor que se comunicam utilizando uma 
interface serial, um bit por vez (ver Figura 3-30). Esses ter¬ 
minais utilizam um conector de 9 pinos ou de 25 pinos, 
dos quais um pino é utilizado para transmitir dados, um é 
para obter dados e um é terra. Os outros pinos são para 
várias funções de controle, a maioria das quais não é utili¬ 
zada. Para enviar um caractere para um terminal RS-232, 
o computador deve transmiti-lo 1 bit por vez, prefixado por 
um bit de partida e seguido por 1 ou 2 bits de parada para 
delimitar o caractere. Um bit de paridade que oferece de¬ 
tecção rudimentar de erro também pode ser inserido pre¬ 
cedendo os bits de parada, embora isso comumente seja 
requerido somente para comunicação com sistemas 
mainframe. Taxas comuns de transmissão de dados são 
9.600, 19 . 2 OO e 38.400bps. Terminais RS-232 são comu¬ 
mente utilizados para comunicação com um computador 
remoto, utilizando um modem e uma linha de telefone. 


Uma vez que tanto os computadores como os terminais 
trabalham internamente com caracteres inteiros mas de¬ 
vem comunicar-se por uma linha serial um bit por vez, 
foram desenvolvidos chips para fazer conversões caractere 
para serial e serial para caractere. Eles são chamados UARTs 
(Universal Asynchronous Receiver Transmitters). Os 
UARTs são ligados ao computador conectando-se placas de 
interface RS-232 no barramento como ilustrado na Figura 
3-31- Os terminais RS-232 estão gradualmente desapare¬ 
cendo, sendo substituídos por PCs e por terminais X, mas 
eles ainda são encontrados em antigos sistemas de main¬ 
frame especialmente em bancos, em reservas de passagens 
aéreas e aplicativos semelhantes. 

Para imprimir um caractere, 0 driver de terminal gra¬ 
va 0 caractere na placa de interface, onde ele é bufferizado 
e, então, é enviado por uma linha serial um bit por vez 
pelo UART. Mesmo a 38.400bps, leva mais de 250 micros- 
segundos para enviar um caractere. Como resultado dessa 
taxa de transmissão lenta, 0 driver geralmente produz um 
caractere para a placa RS-232 e bloqueia, esperando a in¬ 
terrupção gerada pela interface quando 0 caractere for 
transmitido, e 0 UART for capaz de aceitar outro caractere. 
0 UART pode enviar e receber caracteres simultaneamen¬ 
te, como seu nome indica. Uma interrupção também é ge- 


Computador 



Figura 3-30 Um terminal RS-232 comunica-se com um computador por uma linha de 
comunicação, um bit por vez. O computador e 0 terminal são completamente independentes. 
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rada quando um caractere é recebido e normalmente um 
número pequeno de caracteres de entrada pode ser buffe- 
rizado. O driver de terminal deve verificar um registrador 
quando uma interrupção é recebida para determinar a cau¬ 
sa da interrupção. Algumas placas de interface têm uma 
CPU e memória e podem tratar múltiplas linhas, assumin¬ 
do grande parte da carga de E/S da CPU principal. 

Terminais RS-232 podem ser subdivididos em categori¬ 
as, conforme já mencionado. Os mais simples eram termi¬ 
nais de impressão. Os caracteres digitados no teclado eram 
transmitidos para o computador. Os caracteres enviados pelo 
computador eram impressos em papel. Esses terminais es¬ 
tão obsoletos e raramente são vistos hoje em dia. 

Terminais burros de CRT trabalham da mesma ma¬ 
neira, exceto que utilizam uma tela em vez de papel. Eles 
freqüentemente são chamados “ttys de tela” (“ glass ttys”) 
porque são funcionalmente os mesmos que os ttys de im¬ 
pressão. (O termo “tty" é uma abreviação de Teletype®, 
uma antiga empresa que foi pioneira no negócio de termi¬ 
nais de computadores; tty acabou tornando-se sinônimo 
de qualquer terminal.) Os ttys de tela também estão obso¬ 
letos. 

Terminais inteligentes de CRT são de fato miniaturas 
de computadores especializados. Eles têm uma CPU e me¬ 
mória e contêm software, normalmente em ROM. Do pon¬ 
to de vista do sistema operacional, a diferença principal 
entre um tty de tela e um terminal inteligente é que o últi¬ 
mo entende certas seqüências de escape. Por exemplo, en¬ 
viando-se o caractere ASCII ESC (033), seguido por vários 
outros caracteres, pode-se mover o cursor para qualquer 
posição na tela, inserir texto no meio da tela, etc. 


Terminais X 

A última palavra em terminais inteligentes é um ter¬ 
minal que contém uma CPU tão poderosa quanto o com¬ 
putador principal, junto com vários megabytes de memó¬ 
ria, um teclado e um mouse. Um terminal comum desse 
tipo é o terminal X, que roda no XWindow do M.I.T. Em 
geral, os terminais X Window System conversam com o 
computador principal sobre uma rede Ethernet. 

Um terminal X é um computador que executa o sof¬ 
tware X. Alguns produtos são dedicados para executar so¬ 
mente X; outros são computadores de propósito geral que 
simplesmente executam como um programa entre muitos 
outros. De qualquer maneira, um terminal X tem uma 
grande tela de mapa de bits normalmente com resolução 
de 960 x 1.200 ou melhor, em escala de cinza, branco e 
preto ou colorido, um teclado completo e um mouse, nor¬ 
malmente com três botões. 

0 programa dentro do terminal X que recebe a entrada 
do teclado ou do mouse e aceita comandos de um compu¬ 
tador remoto é chamado servidor X. Ele se comunica pela 
rede com clientes X que rodam em algum host remoto. 
Pode parecer estranho ter 0 servidor X dentro do terminal e 
os clientes no host remoto, mas 0 trabalho do servidor X é 
exibir bits; então, faz sentido estar próximo do usuário. A 
organização cliente-servidor é mostrada na Figura 3-31- 

A tela do terminal X contém algumas janelas, cada uma 
na forma de uma grade retangular de pixels. Cada janela 
normalmente tem uma barra de título na parte superior, 
uma barra de rolagem à esquerda e uma caixa de redi¬ 
mensionamento no canto superior direito. Um dos clientes 


Terminal X 



Rede 


Figura 3-31 Os clientes e servidores noX Window System do M.I.T. 
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X é um programa chamado gerenciador de janelas. Seu 
trabalho é controlar a criação, a exclusão e o movimento 
das janelas na tela. Para gerenciar janelas, ele envia co¬ 
mandos para o servidor X instruindo o que fazer. Esses co¬ 
mandos incluem desenhar um ponto, desenhar uma linha, 
desenhar um retângulo, desenhar um polígono, preencher 
um retângulo, preencher um polígono e assim por diante. 

0 trabalho do servidor X é coordenar entrada de mou¬ 
se, teclado e clientes X e atualizar o monitor de maneira 
correspondente. Ele precisa monitorar qual janela está atu¬ 
almente selecionada (onde o ponteiro do mouse está), para 
saber para qual cliente enviar qualquer nova entrada de 
teclado. 

3-9.2 Software de Terminal 

O teclado e 0 monitor são dispositivos quase indepen¬ 
dentes, assim os trataremos separadamente aqui. (Eles não 
são precisamente independentes, já que caracteres digita¬ 
dos devem ser exibidos na tela.) No MIMX, os drivers de 
teclado e de tela são partes da mesma tarefa; em outros 
sistemas eles podem dividir-se em drivers distintos. 

O Software de Entrada 

O trabalho básico do driver de teclado é reunir entra¬ 
das do teclado e passar para os programas de usuário quan¬ 
do elas forem lidas do terminal. Duas filosofias podem ser 
adotadas para 0 driver. Na primeira, 0 trabalho do driver é 
simplesmente aceitar entrada e passá-la para cima inalte¬ 
rada. Um programa que lê do terminal obtém uma sequên¬ 
cia de códigos ASCII brutos. (Fornecer aos programas de 
usuário os números de tecla é muito primitivo, além de ser 
grandemente dependente da máquina.) 

Essa filosofia atende bem às necessidades dos editores 
de tela sofisticados como 0 emacs, que permite que 0 usu¬ 
ário associe uma ação arbitrária a qualquer caractere ou 
seqüência de caracteres. Entretanto, isso significa que se 0 
usuário digitar dsta em vez de data e, então, corrigir 0 erro 
digitando três backs/iace e ata. seguido por um retorno de 
carro, 0 programa de usuário receberá todos os 11 códigos 
ASCII digitados. 

A maioria dos programas não exige tantos detalhes as¬ 
sim. Eles apenas querem a entrada corrigida, não a seqüên¬ 
cia exata de como foi produzida. Essa observação conduz a 
segunda filosofia: 0 driver trata toda edição entre linhas e 
entrega somente linhas corrigidas para os programas de 
usuário. A primeira filosofia é baseada em caractere; a se¬ 
gunda é baseada em linha. Originalmente elas eram refe¬ 
ridas como modo bruto (raw mode) e modo processa¬ 
do {cookedmode) , respectivamente. 0 padrão POSIX utili¬ 
za 0 termo menos pitoresco modo canônico para descre¬ 
ver 0 modo baseado em linha. Na maioria dos sistemas do 
modo canônico significa uma configuração bem-defini- 
da. O modo não-canônico é equivalente ao modo bruto, 
embora muitos detalhes do comportamento do terminal 
possam ser alterados. Os sistemas compatíveis com POSIX 


oferecem várias funções de biblioteca que suportam seleci¬ 
onar qualquer um dos modos e alterar muitos aspectos da 
configuração do terminal. No MINIX, a chamada de siste¬ 
ma 10 CTL suporta essas funções. 

A primeira tarefa do driver de teclado é completar ca¬ 
racteres. Se cada pressionamento de tecla causar uma in¬ 
terrupção, 0 driver pode obter 0 caractere durante a inter¬ 
rupção. Se as interrupções são transformadas em mensa¬ 
gens pelo software de baixo nível, é possível colocar 0 ca¬ 
ractere recentemente obtido na mensagem. Alternativamen¬ 
te, ele pode ser colocado em um pequeno buffer na memó¬ 
ria e a mensagem utilizada para informar 0 driver de que 
algo chegou. A última abordagem é realmente mais segu¬ 
ra se uma mensagem puder ser enviada somente para um 
processo em espera e houver alguma chance de 0 driver de 
teclado ainda estar ocupado com 0 caractere anterior. 

Uma vez que 0 driver recebeu 0 caractere, ele deve co¬ 
meçar a processá-lo. Se 0 teclado entrega números de tecla 
em vez dos códigos de caractere utilizados pelo software 
aplicativo, então, 0 driver deve converter os códigos utili¬ 
zando uma tabela. Nem todos os sistemas compatíveis com 
0 padrão IBM utilizam a numeração padrão de teclas; en¬ 
tão, se 0 driver quiser suportar essas máquinas, ele deverá 
mapear teclados diferentes com tabelas diferentes. Uma 
abordagem simples é compilar uma tabela que mapeia os 
códigos fornecidos pelo teclado para os códigos ASCII {Ame¬ 
rican Standard Code for Information Interchange) no 
driver de teclado, mas isso é insatisfatório para usuários de 
idiomas que não 0 inglês. Os teclados são organizados dife¬ 
rentemente em países diferentes, e 0 conjunto de caracteres 
ASCII não é adequado nem mesmo para a maioria das pes¬ 
soas no hemisfério Ocidental, onde os idiomas espanhol, 
português e francês precisam de caracteres acentuados e 
marcas de pontuação não-utilizadas no inglês. Para res¬ 
ponder â necessidade de flexibilidade nos leiautes de tecla¬ 
do para diferentes idiomas, muitos sistemas operacionais 
oferecem mapas de teclado ou páginas de código carre¬ 
gáveis, que tornam possível escolher 0 mapeamento entre 
códigos de teclado e códigos entregues para 0 aplicativo, 
seja quando 0 sistema é inicializado. seja mais tarde. 

Se 0 terminal estiver no modo canônico (processado), 
os caracteres devem ser armazenados até que uma linha 
inteira seja acumulada, pois 0 usuário pode depois decidir 
apagar parte dela. Mesmo que 0 terminal esteja no modo 
bruto, 0 programa pode ainda não ter solicitado a entrada, 
assim os caracteres devem ser bufferizados para permitir 
armazenar teclas digitadas. (Projetistas de sistema que não 
permitem que os usuários digitem muito adiante, isto é, 
que não oferecem um buffer de teclado razoável, deveriam 
ser mergulhados em um balde de piche e cobertos de penas, 
ou, pior ainda, forçados a utilizar seu próprio sistema.) 

Duas abordagens para bufferização de caracteres são 
comuns. Na primeira, 0 driver contém um conjunto cen¬ 
tral de buffers, cada buffer armazenando talvez 10 caracte¬ 
res. Associada com cada terminal está uma estrutura de 
dados, que contém, entre outros itens, um ponteiro para a 
cadeia de buffers para a entrada coletada desse terminal. À 
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medida que mais caracteres são digitados, mais buffers são 
adquiridos e incluídos na cadeia. Quando os caracteres são 
passados para um programa de usuário, os buffers são re¬ 
movidos e devolvidos para o conjunto central. 

A outra abordagem é fazer a bufferização diretamente 
na própria estrutura de dados do terminal, sem nenhum 
conjunto de buffers central. Uma vez que é comum os usu¬ 
ários digitarem um comando que levará algum tempo (di¬ 
gamos, uma compilação) e, então, digitar algumas linhas 
adiante, por segurança o driver deveria atribuir algo como 
uns 200 caracteres por terminai. Em um sistema de com¬ 
partilhamento de tempo de grande escala com 100 termi¬ 
nais, alocar 20K o tempo todo para o type ahead é eviden¬ 
temente exagerado, então, um conjunto central buffers com 
espaço para talvez 5K é provavelmente suficiente. Por ou¬ 
tro lado, um buffer dedicado por terminal torna o driver 
mais simples (não há gerenciamento de lista encadeada) 
e seria preferido em computadores pessoais com somente 
um ou dois terminais. A Figura 3-32 mostra a diferença 
entre esses dois métodos. 

Embora o teclado e o monitor sejam dispositivos lógi¬ 
cos separados, muitos usuários cresceram acostumados a 
ver os caracteres que eles acabam de digitar aparecer na 
tela. Alguns terminais (antigos) exibem automaticamente 
(em hardware) o que se acabou de digitar, o que não so¬ 
mente é um incômodo quando senhas estão sendo inseri¬ 
das como também limita grandemente a flexibilidade dos 
editores sofisticados e de outros programas. Felizmente, os 
terminais mais modernos não exibem nada quando teclas 
são digitadas. Portanto cabe ao software exibir a entrada. 
Esse processo é chamado ecoamento. 

O ecoamento é complicado pelo fato de que um pro¬ 
grama pode estar escrevendo na tela enquanto o usuário 
está digitando. No mínimo, o driver de teclado tem de ima¬ 


ginar onde colocar a nova entrada sem ser sobrescrito pela 
saída de programa. 

O ecoamento também fica complicado quando mais de 
80 caracteres são digitados em um terminal com linhas de 
80 caracteres. Dependendo do aplicativo, a quebra de li¬ 
nha pode ser apropriada. Alguns drivers simplesmente trun¬ 
cam as linhas para 80 caracteres jogando fora todos os ca¬ 
racteres além de coluna 80. 

Outro problema é o tratamento de tabulação. A maio¬ 
ria dos terminais tem uma tecla de tabulação, mas poucos 
podem tratar tabulação na saída. Cabe ao driver calcular 
onde o cursor está atualmente localizado, levar em conta 
tanto a saída dos programas como a saída de ecoamento e 
calcular o número adequado de espaços a ser ecoado. 

Agora chegamos ao problema de equivalência de dis¬ 
positivo. Logicamente, no fim de uma linha de texto, que¬ 
remos um retorno de carro, mover de volta o cursor para a 
coluna 1 e uma quebra de linha, para avançar para a pró¬ 
xima linha. Exigir que os usuários digitem os dois coman¬ 
dos no fim de cada linha não daria certo (embora alguns 
terminais tenha uma tecla que gera ambos, com 50% de 
chance de fazer isso na ordem que o software quer). Cabe 
ao driver converter a entrada para o formato interno pa¬ 
drão utilizado pelo sistema operacional. 

Se a forma-padrão é simplesmente armazenar uma 
quebra de linha (a convenção do MINTX), então, os retor¬ 
nos de carro transformam-se em quebras de linha. Se o 
formato interno é armazenar ambos, então, o driver deve 
gerar uma quebra de linha quando receber um retorno de 
carro e retorno de carro quando receber uma quebra de 
linha. Independentemente da convenção interna, o termi¬ 
nal pode solicitar que tanto uma quebra de linha como 
um retorno de carro sejam ecoados a fim de atualizar a 
tela adequadamente. Uma vez que um computador de gran- 
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Figura 3-32 (a) Conjunto central de buffers. (b) Buffer dedicado para cada terminal. 
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de porte pode ter uma grande variedade de terminais dife¬ 
rentes conectados a ele, cabe ao driver de teclado receber 
todas as combinações diferentes de quebra de linha e retor¬ 
no de carro convertidos ao padrão interno do sistema e or¬ 
ganizar para todo ecoamento ser feito corretamente. 

Um problema relacionado é a sincronização de retorno 
de carro e as quebras de linha. Em alguns terminais, pode 
levar mais tempo para exibir um retorno de carro ou que¬ 
bra de linha que uma letra ou um número. Se o micropro¬ 
cessador dentro do terminal precisar realmente copiar um 
bloco grande de texto para conseguir fazer a tela rolar, en¬ 
tão, as quebras de linha podem ser lentas. Se um cabeçote 
de impressão mecânico precisa ser retornado para a mar¬ 
gem esquerda do papel, os retornos de carro podem ser len¬ 
tos. Em ambos os casos, cabe ao driver inserir os caracte¬ 
res de preenchimento (caracteres nulos fictícios) no flu¬ 
xo de saída ou simplesmente interromper a saída por tem¬ 
po suficiente para o terminal alcançá-lo. A quantidade de 
tempo de retardo freqüentemente está relacionada com a 
velocidade do terminal, por exemplo, a 4800bps ou mais 
lento, talvez nenhum retardo seja necessário, mas a 9600bps 
ou velocidade mais alta, talvez os caracteres de preenchi¬ 
mento sejam necessários. Os terminais com tabulações de 
hardware, especialmente aqueles de hardcopy, também 
podem solicitar um retardo depois de uma tabulação. 

Ao operar em modo canônico, vários caracteres de en¬ 
trada têm significados especiais. A Figura 3-33 mostra to¬ 
dos os caracteres especiais necessários para o POSIX e os 
adicionais reconhecidos pelo minix. Os padrões são que to¬ 
dos os caracteres de controle não devem gerar conflito com 
a entrada de texto nem com os códigos utilizados por pro¬ 
gramas, mas todos exceto os dois últimos podem ser alte¬ 
rados utilizando o comando stty, se desejado. Versões mais 


antigas do UNIX utilizavam diferentes padrões para muitos 
desses. 

0 caractere ERASE permite que o usuário apague o ca¬ 
ractere que acabou de digitar. No MINX ele é o backspace 
(CTRL-H). Ele não é adicionado à fila de caracteres, mas, 
em vez disso, remove o caractere anterior da fila. Ele deve 
ser ecoado como uma seqüência de três caracteres, backs¬ 
pace, espaço e backspace, a fim de remover o caractere 
anterior da tela. Se o caractere anterior era uma tabula¬ 
ção, a operação de apagá-lo requer monitorar onde o cur¬ 
sor estava antes da tabulação. Na maioria dos sistemas, 
usar backspace apagará apenas os caracteres na linha atual. 
Não apagará retorno de carro e voltará à linha anterior. 

Quando o usuário nota um erro no início da linha sen¬ 
do digitada, é com freqüência conveniente apagar a linha 
inteira e iniciar novamente. 0 caractere KJLL (no MINIX o 
CRTL-U) apaga a linha inteira. 0 minix faz a linha apaga¬ 
da desaparecer da tela, mas alguns sistemas ecoam-na com 
mais um retorno de carro e com uma quebra de linha por¬ 
que alguns usuários querem ver a linha antiga. Portanto, 
ecoar KILL é uma questão de gosto. Como com ERASE nor¬ 
malmente não é possível voltar além da linha atual. Quando 
um bloco de caracteres é eliminado, ele pode ou não levar 
ao problema de o driver retornar buffers para o pool, se 
um é utilizado. 

Eventualmente os caracteres ERASE ou KILL devem ser 
inseridos como dados normais. 0 caractere LNEXT serve 
como um caractere de escape. No minix, Ctrl é o padrão. 
Como um exemplo, os sistemas UNIX mais antigos freqüen¬ 
temente utilizavam o sinal @ para KILL, mas o sistema de 
correio da Internet utiliza endereços na forma linda@ 
cs.washington.edu. Alguém que se sinta mais confortável 
com as convenções mais antigas pode redefinir KILL como 
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Comentário 

CRTL-D 

EOF 

Fim de arquivo 
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Fim de linha (não definido) 

CRTL-H 

ERASE 

Retroceder um caractere 

DEL 

INTR 

Interrompe o processo (SIGINT) 
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KILL 

Apaga a linha inteira que esta sendo digitada 

CRTLA 

QUIT 

Força dump de núcleo (SIGQUIT) 

CRTL-Z 

SUSP 

Suspende (ignorado pelo MINIX) 

CRTL-Q 

START 

Inicia a saída 

CRTL-S 

STOP 

Pára a saída 

CRTL-R 

REPRINT 

Reexibe a entrada (extensão do MINIX) 

CRTL-V 

LNEXT 

Literal seguinte (extensão do MINIX) 

CRTL-0 

DISCARD 

Descarta a saída (extensão do MINIX) 
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Retorno de carro (inalterável) 
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Quebra de linha (inalterável) 


Figura 3-33 Caracteres que recebem tratamento especial no modo canônico. 
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@, mas, então, é necessário inserir um sinal @ literal¬ 
mente para endereçar correio eletrônico. Isso pode ser feito 
digitando-se CTRL-V @.0 próprio CTRL-V pode ser inseri¬ 
do literalmente digitando-se CTRL-V CTRL-V. Depois de ver 
um CTRL-V, o driver configura um sinalizador avisando 
que o próximo caractere é isento de processamento especi¬ 
al. 0 caractere LNEXTem si não entra na fila de caracteres. 

Para permitir que os usuários impeçam a rolagem da 
imagem da tela para fora do campo de visão, códigos de 
controle são oferecidos para congelar a tela e reiniciá-la 
mais tarde. No MINIX, esses códigos são STOP (CTRL-S) e 
SJART (CTRL-Q), respectivamente. Eles não são armaze¬ 
nados, mas utilizados para ligar e para desligar um sinali¬ 
zador na estrutura de dados do terminal. Sempre que uma 
saída é tentada, o sinalizador é inspecionado. Se estiver li¬ 
gado, nenhuma saída ocorre. Normalmente, o ecoamento 
também é suprimido junto com a saída do programa. 

Com freqüência, é necessário eliminar um programa 
que está sendo depurado. Os caracteres INTR (DEL) e QUIT 
(CTRLA) podem ser utilizados para esse propósito. No MI- 
MX, DEL envia o sinal de SIGINT para todos os processos 
iniciados a partir do terminal. Implementar DEL é bem di¬ 
fícil. A parte difícil é levar as informações do driver para a 
parte do sistema que trata sinais, que, afinal de contas, não 
solicitou tais informações. 0 CTRLA é semelhante a DEL, 
exceto que envia o sinal de SlGQülT, que força um dump de 
núcleo se não capturado ou ignorado. Quando qualquer 
uma dessas teclas é pressionada, o driver deve ecoar um 
retorno de carro e uma quebra de linha e descartar toda 
entrada acumulada para permitir uma inicialização atua¬ 
lizada. 0 valor-padrão para INTR é, com freqüência, CTRL- 
C em vez de DEL, pois muitos programas utilizam DEL in- 
tercambiavelmente com o backspace para edição. 

Outro caractere especial é EOF (CTRL-D), que no MINIX 
faz com que qualquer solicitação pendente para o terminal 
seja atendida com qualquer coisa que esteja disponível no 
buffer, mesmo que o buffer esteja vazio. Digitar CTRL-D no 
início de uma linha faz com que o programa obtenha um 
leitura de 0 bytes, que convencionalmente é interpretado 
como fim de arquivo e faz com que a maioria dos progra¬ 
mas comporte-se da mesma maneira como se comportaria 
ao ver o fim de arquivo em um arquivo de entrada. 

Alguns drivers de terminal oferecem muito mais recur¬ 
sos de edição entre linhas do que esboçamos aqui. Eles têm 
caracteres especiais de controle para apagar uma palavra, 


struct termios { 
tcflagj cjflag; 
tcflagj c_oflag; 
tcflagj c_cflag; 
tcflagj cjflag; 
speedj cjspeed; 
speedj c ospeed; 
ccj c_cc[NCCS]; 

}; 


pular caracteres ou palavras para trás ou para frente para 
ir para o começo ou para o fim da linha sendo digitada, 
etc. Adicionar todas essas funções ao driver de terminal 
torna-o muito maior e, ademais, tudo isso é desperdiçado 
quando se utilizam editores de tela que trabalham em modo 
bruto no final das contas. 

Para permitir que os programas controlem parâmetros 
de terminal, o POSix requer que várias funções estejam dis¬ 
poníveis na biblioteca-padrão, das quais as mais impor¬ 
tantes são tcgetattr e tcsetattr. Tcgetattr recupera uma có¬ 
pia da estrutura mostrada na Figura 3-34, a estrutura ter¬ 
mios, que contém todas as informações necessárias para 
mudar caracteres especiais, para configurar modos e para 
modificar outras características de um terminal. Um pro¬ 
grama pode examinar as configurações atuais e modificá- 
las conforme desejado. Tcsetattr. então, grava a estrutura 
de volta à tarefa de terminal. 

O posix não especifica se seus requisitos devem ser im¬ 
plementados por funções de biblioteca ou por chamadas 
de sistema. 0 MINIX oferece uma chamada de sistema, IOC- 
TL, chamada por 

ioctl(file_descriptor, request, argp); 

que é utilizada para examinar e para modificar as confi¬ 
gurações de muitos dispositivos de E/S. Essa chamada é 
utilizada para implementar as funções tcgetattr e tcsetattr. 
A variável request especifica se a estrutura termios é para 
ser lida ou gravada e, no último caso, se a solicitação deve 
ser atendida imediatamente ou adiada até que toda a saída 
atualmente enfileirada esteja completa. A variável argp é 
um ponteiro para uma estrutura termios no programa de 
chamada. Essa opção particular de comunicação entre o 
programa e o driver foi escolhida por sua compatibilidade 
com UNIX, não pela sua beleza inerente. 

Algumas notas sobre a estrutura termios são necessári¬ 
as. As quatro palavras de sinalização oferecem muita flexi¬ 
bilidade. Os bits individuais em cjflag controlam várias 
maneiras como a entrada é tratada. Por exemplo, o bit ICR- 
NL faz com que os caracteres CR sejam convertidos em NL 
na entrada. Esse sinalizador é ligado por padrão no MINTX. 
O cjflag armazena bits que afetam o processamento da 
saída. Por exemplo, o bit OPOST ativa processamento de 
saída. Ele e o bit ONLCR, que faz com que os caracteres NL 
na saída sejam convertidos em uma seqüência CR NL. tam¬ 
bém são configurados por padrão no MINIX. O cjflag é o 


/* modos de entrada 7 
/* modos de saída 7 
/* modos de controle 7 
/* modos locais 7 
/* taxa de entrada 7 
/* taxa de saída 7 
/* caracteres de controle 7 


Figura 3-34 A estrutura termios. No minix tc JlagJéumshort, speedjéxxmint, ccjéumchar. 
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sinalizador de controle. As configurações padrão para o Mi- 
nix permitem que uma linha receba caracteres de 8 bits e 
fazem com que um modem desligue se um usuário desco- 
nectar-se da linha. 0 cjflag é o campo dos sinalizadores 
de modo local. Um bit, ECHO, ativa o ecoamento (isso pode 
ser desativado durante um login para oferecer segurança 
ao inserir-se uma senha). Seu bit mais importante é o [CA¬ 
NON, que ativa o modo canônico. Com /G4MW desligado, 
há várias possibilidades. Se todas as outras configurações 
são deixadas em seus padrões, um modo idêntico ao tradi¬ 
cional modo cbreak é iniciado. Nesse modo, os caracteres 
são passados para o programa sem esperar uma linha com¬ 
pleta, mas os caracteres INTR, QUIT. START e STOP man¬ 
têm seus efeitos. Entretanto, todos esses podem ser desati¬ 
vados redefinindo bits nos sinalizadores, produzindo o equi¬ 
valente do modo bruto tradicional. 

Os vários caracteres especiais que podem ser mudados, 
incluindo aqueles que são extensões do minix, são armaze¬ 
nados na matriz c_cc. Essa matriz também armazena dois 
parâmetros que são utilizados no modo não-canônico. A 
quantidade MIN. armazenada em c_cc[VMIN], especifica 
o número mínimo de caracteres que deve ser recebido para 
satisfazer a chamada RKAd. A quantidade TIME em c_cc 
[VTIME] define um limite de tempo para essas chamadas. 
MINe TIME interagem como mostrado na Figura 3-35. Uma 
chamada que solicita N bytes é ilustrada. Com TIME = 0 e 
MIN = 1, o comportamento é semelhante ao modo bruto 
tradicional. 

O Software de Saída 

A saída é mais simples que a entrada, mas drivers para 
terminais RS-232 são radicalmente diferentes dos drivers 
para terminais de memória mapeada. 0 método que co- 
mumente é utilizado para terminais RS-232 é ter buffers 
de saída associados com cada terminal. Os buffers podem 
vir do mesmo pool que os buffers de entrada ou são dedica¬ 
dos, como a entrada. Quando os programas gravam no ter¬ 
minal, a saída é primeiro copiada para os buffers. De ma¬ 
neira semelhante, a saída de ecoamento também é copia¬ 
da para os buffers. Depois que toda a saída foi copiada para 
os buffers (ou se os buffers estiverem cheios), é feita a saí¬ 
da do primeiro caractere, e o driver vai dormir. Quando a 


interrupção chega, é feita a saída do próximo caractere e 
assim por diante. 

Com terminais mapeados em memória, é possível um 
esquema mais simples. Os caracteres a serem impressos são 
extraídos, um por vez, do espaço do usuário e colocados 
diretamente na RAM de vídeo. Com terminais RS-232, cada 
caractere a sair é simplesmente enviado pela linha para o 
terminal. Com memória mapeada, alguns caracteres exi¬ 
gem tratamento especial, entre eles, backspace, retorno de 
carro, quebra de linha e sinal sonoro (CTRL-G). Um dri¬ 
ver para um terminal de memória mapeada deve monito¬ 
rar em software a posição atual na RAM de vídeo, de modo 
que os caracteres imprimíveis possam ser colocados ali e a 
posição atual avançada. Backspace, retomo de carro e que¬ 
bra de linha exigem que essa posição seja atualizada apro¬ 
priadamente. 

Em particular, quando uma quebra de linha é emitida 
na última linha, a tela deve ser rolada. Para ver como a 
rolagem funciona, veja a Figura 3-29- Se a controladora 
de vídeo sempre começasse a ler a RAM em OxBOOOO, a 
única maneira de rolar a tela seria copiar 24 x 80 caracte¬ 
res (cada caractere solicitando 2 bytes) de 0 xOOBOOAO para 
OxBOOOO, uma proposta que consome tempo. 

Felizmente, o hardware normalmente oferece alguma 
ajuda aqui. A maioria das controladoras de vídeo contém 
um registrador que determina onde na RAM de vídeo deve- 
se começar a buscar bytes para a linha superior da tela. 
Configurando esse registrador para apontar para OxOOBOOAO 
em vez de OxBOOOO, a linha que era previamente número 
dois move-se para o topo, e a tela inteira rola para cima 
uma linha. A única outra coisa que o driver deve fazer é 
copiar o que for necessário para a nova linha final. Quan¬ 
do a controladora de vídeo chegar ao topo da RAM, ela sim¬ 
plesmente continua a buscar bytes, começando no endere¬ 
ço mais baixo. 

Outra questão com que o driver deve lidar em um ter¬ 
minal mapeado em memória é o posicionamento do cur¬ 
sor. Mais uma vez, o hardware geralmente oferece algum 
auxílio na forma de um registrador que informa onde o 
cursor deve ir parar. Por fim, há o problema do sinal sono¬ 
ro que é emitido dando saída a uma onda senoidal ou qua¬ 
drada para os alto-falantes, uma parte do computador bem 
separada da RAM de vídeo. 



TIME = 0 

TIME > 0 

MIN = 0 

Retorna imediatamente com quaisquer 
coisas que estejam disponíveis, 

0 a N bytes 

O temporizador inicia imediatamente. 
Retorna com o primeiro byte inserido 
ou com 0 bytes depois do tempo limite 

MIN > 0 

Retorna com pelo menos MIN e até 

N bytes. Possível bloco indefinido. 

0 temporizador interbyte inicia após o 
primeiro byte. Retorna N bytes se atingir 
o tempo limite. Possível bloco indefinido. 


Figura 3-35 MIN e TIME determinam quando uma chamada a read retorna em modo não-canônico. Né o número de bytes exigidos. 
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Vale notar que muitas das questões com que o driver de 
terminal defronta-se para um monitor mapeado em me¬ 
mória (rolar a tela, emitir um sinal sonoro e assim por 
diante) também são encaradas pelo microprocessador den¬ 
tro de um terminal RS-232. Do ponto de vista do micropro¬ 
cessador, ele é o processador principal em um sistema com 
um monitor mapeado em memória. 

Os editores de tela e muitos outros programas sofistica¬ 
dos precisam ser capazes de atualizar a tela de maneiras 
mais complexas que simplesmente rolar texto sobre o fun¬ 
do do monitor. Para atendê-los, muitos drivers de termi¬ 
nal suportam uma variedade de seqüências de escape. 
Embora alguns terminais suportem conjuntos de seqüên¬ 
cias de escape idiossincrásicos, é vantajoso ter um padrão 
para facilitar a adaptação do software de um sistema para 
outro. 0 American National Standards Institute (ANSI) 
definiu um conjunto de seqüências de escape-padrão, e o 
MINIX suporta um subconjunto das seqüências do ANSI, 
mostrado na Figura 3-36, que é adequado para muitas ope¬ 
rações comuns. Quando o driver vê o caractere que inicia 
as seqüências de escape, ele ativa um sinalizador e espera 
até que o resto da seqüência de escape entre. Quando tudo 
tiver chegado, o driver deve executar a seqüência em sof¬ 
tware. Inserir e excluir texto exige mover blocos de carac¬ 
teres pela da RAM de vídeo. O hardware não oferece qual¬ 
quer ajuda exceto rolar e exibir o cursor. 

3-9-3 Visão Geral do Driver de 
Terminal no MINIX 

O driver de terminal é contido em quatro arquivos de C 
(seis se o suporte a RS-232 e a pseudoterminal forem ati¬ 
vados) e juntos eles constituem de longe o maior driver no 


MINIX. 0 tamanho do driver de terminal é em parte expli¬ 
cado notando que o driver trata o teclado e o monitor, cada 
um dos quais é um dispositivo complicado e com suas pró¬ 
prias particularidades, bem como dois outros tipos de ter¬ 
minal opcionais. Além disso, a maioria das pessoas surpre¬ 
ende-se ao descobrir que a E/S de terminal requer 30 vezes 
mais código que o agendador. (Essa sensação é reforçada 
vendo os numerosos livros sobre sistemas operacionais que 
dedicam 30 vezes mais espaço ao agendamento do que a 
toda a E/S combinada.) 

0 driver de terminal aceita sete tipos de mensagem: 

1. Ler do terminal (a partir do sistema de arquivos 
em nome de um processo de usuário). 

2. Gravar no terminal (a partir do sistema de arqui¬ 
vos em nome de um processo de usuário). 

3. Configurar parâmetros de terminal para IOTCL (a 
partir do sistema de arquivos em nome de um pro¬ 
cesso de usuário). 

4. E/S ocorrida durante o último tique do relógio (a 
partir da interrupção de relógio). 

5. Cancelar a solicitação anterior (a partir do siste¬ 
ma de arquivos quando um sinal ocorre). 

6. Abrir um dispositivo. 

7. Fechar um dispositivo. 

As mensagens para ler e gravar têm o mesmo formato que 
o mostrado na Figura 3-15, exceto que nenhum campo 
POS/TIONé necessário. Com um disco, o programa precisa 
especificar que bloco quer ler. Com um terminal, não há 
nenhuma escolha: o programa sempre recebe o próximo 
caractere digitado. Os terminais não suportam buscas. 

As funções POSIX tcgetattr e tcgetattr, utilizadas para 
examinar e para modificar atributos de terminal (proprie- 


Seqüência de escape 

Significado 

ESC [ nA 

Move para cima n linhas 

ESC [ nB 

Move para baixo n linhas 

ESC [ nC 

Move para a direita n espaços 

ESC [ ND 

Move à esquerda n espaços 

ESC [ nr, n H 

Move cursor para (m,ri) 

ESC[s J 

Limpa a tela do cursor (0 ao fim, 1 do início, 2 tudo) 

ESC[s K 

Limpa a linha do cursor (0 ao fim, 1 do início, 2 tudo) 

ESC [ n L 

Insere n linhas no cursor 

ESC [ n M 

Exclui n linhas no cursor 

ESC [ n P 

Exclui n caracteres no cursor 

ESC[ n @ 

Insere n caracteres no cursor 

ESC [nm 

Ativa estilo de exibição (0=normal, 4=negrito, 5=intermitente, 7=inverso) 

ESC M 

Rola a tela para trás se o cursor está na linha superior 


Figura 3-36 As seqüências de escape ANSI aceitas pelo driver de terminal na saída. ESC denota o caractere de escape ASCII (OxlB), 
e n, mes são parâmetros numéricos opcionais. 
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dades), são suportadas pela chamada de sistema IOCTL. Uma 
boa prática de programação é utilizar essas funções e ou¬ 
tras em include/termios.h e deixar para a biblioteca de C 
converter chamadas de biblioteca em chamadas de siste¬ 
ma IOCTL Há, entretanto, algumas operações de controle 
necessárias para o MlNix que não são oferecidas no POSix 
para, por exemplo, carregar um mapa de teclado alternati¬ 
vo; para essas operações o programador deve utilizar IOCTL 
explicitamente. 

A mensagem enviada para o driver por uma chamada 
de sistema IOCTL contém um código de solicitação de fun¬ 
ção e um ponteiro. Para a função tcsetattr, uma chamada 
IOCTL é feita com um tipo de solicitação TCSETS, TCSETSW 
ou TCSETSF e um ponteiro para uma estrutura termios 
como mostrado na Figura 3-34. Todas essas chamadas subs¬ 
tituem o conjunto de atributos atuais por um novo con¬ 
junto, sendo que as diferenças são que uma solicitação 
TCSETS tem efeito imediato, enquanto uma solicitação TC¬ 
SETSW não tem efeito até que toda saída tenha sido trans¬ 
mitida e uma TCSETSF espera a saída terminar e descarta 
toda entrada que ainda não foi lida. Tcgetattr é traduzido 
em uma chamada IOCTL com um tipo de solicitação TCGETS 
e retorna para o processo chamador uma estrutura termi¬ 
os preenchida; assim, o estado atual de um dispositivo pode 
ser examinado. As chamadas IOCTL que não correspondem 
a funções definidas pelo POSix, como a solicitação FJOCS- 
MAP. utilizada para carregar um novo mapa de teclado, 
passam ponteiros para outros tipos de estruturas, neste caso 
para uma estrutura keymapj que é uma estrutura de 1536 
bytes (códigos de 16 bits para 128 teclas x 6 modificado¬ 
res). A Figura 3-43 resume como as chamadas POSix-pa- 
drão são convertidas em chamadas de sistema IOCTL. 

O driver de terminal utiliza uma estrutura principal de 
dados, ttyjable, que é uma matriz de estruturas tty, uma 
por terminal. Um PC-padrão tem apenas um teclado e um 
monitor, mas o MINIX pode suportar até oito terminais vir¬ 
tuais, dependendo da quantidade de memória na placa 
adaptadora do monitor. Isso permite que a pessoa no con¬ 
sole conecte-se múltiplas vezes, troque a saída de monitor 
e a entrada de teclado de um “usuário” para outro. Com 
dois consoles virtuais, pressionar ALT-F2 seleciona o segun¬ 
do, e ALT-F1 retorna o primeiro. ALT também pode ser uti¬ 
lizada com as teclas de seta. Além disso, linhas seriais po¬ 
dem suportar dois usuários em posições remotas, conecta¬ 
dos por cabo RS-232 ou por modem, e os pseudotermi- 
nais podem suportar usuários conectados por uma rede. O 
driver foi escrito para facilitar o acréscimo de terminais 
adicionais. A configuração padrão ilustrada no código-fonte 
desse texto tem dois consoles virtuais, com linhas seriais e 
pseudoterminais desativados. 

Cada estrutura tty em ttyjable monitora tanto a en¬ 
trada como a saída. Para a entrada, ela armazena uma 
fila de todos os caracteres que foram digitados, mas ainda 
não lidos pelo programa, as informações sobre solicitações 
para ler caracteres que ainda não foram recebidos e as in¬ 
formações de tempo limite, para que a entrada possa ser 
solicitada sem que a tarefa bloqueie permanentemente se 


nenhum caractere for digitado. Para a saída, ela armaze¬ 
na os parâmetros das solicitações de gravação que ainda 
não terminaram. Outros campos armazenam diversas va¬ 
riáveis gerais, como a estrutura termios discutida anterior¬ 
mente, que afeta muitas propriedades tanto da entrada 
como da saída. Há também um campo na estrutura tty 
apontando para as informações que são necessárias para 
uma classe particular de dispositivos, mas não são neces¬ 
sárias na entrada ttyjable para cada dispositivo. Por exem¬ 
plo, a parte dependente do hardware do driver de console 
precisa da posição atual na tela e na RAM de vídeo e do 
byte de atributo atual para o monitor, mas essas informa¬ 
ções não são necessárias para suportar uma linha RS-232. 
As estruturas de dados privadas para cada tipo de dispositi¬ 
vo são também onde os buffers que recebem entrada das 
rotinas de serviço de interrupções estão localizados. Dispo¬ 
sitivos lentos, como o teclado, não precisam de buffers tão 
grandes quanto aqueles necessários para dispositivos velo¬ 
zes. 

Entrada de Terminal 

Para melhor entender como o driver funciona, veja¬ 
mos primeiro como os caracteres digitados no terminal fa¬ 
zem seu caminho do sistema ao programa que os quer. 

Quando um usuário conecta-se no console do sistema, 
um shell é criado para ele com /dev/console como entra- 
da-padrão, como saída-padrão e como erro padrão. 0 shell 
inicia e tenta ler da entrada-padrão chamando o procedi¬ 
mento de biblioteca read. Esse procedimento envia uma 
mensagem que contém o descritor de arquivo, o endereço 
do buffer, e a contagem, para o sistema de arquivos. Essa 
mensagem é mostrada como (1) na Figura 3-37. Depois de 
enviar a mensagem, o shell bloqueia, esperando a respos¬ 
ta. (Processos de usuário executam somente a primitiva 
SEND_REC, que combina um SLND com um RLCEIVE a 
partir do processo para o qual foi enviado.) 

0 sistema de arquivos recebe a mensagem e localiza o 
nó-i correspondente ao descritor de arquivo especificado. 
Esse nó-i é para o arquivo de caractere especial /dev/con¬ 
sole e contém os números dos dispositivo primários e se¬ 
cundários para o terminal. 0 tipo de dispositivo primário 
para terminais é 4; para o console o número de dispositivo 
secundário é 0. 

O sistema de arquivos pesquisa em seu mapa de dispo¬ 
sitivos, dmap. para localizar o número da tarefa de termi¬ 
nal. Então, envia uma mensagem para a tarefa de termi¬ 
nal, mostrada como (2) na Figura 3-37. Normalmente, o 
usuário não terá digitado nada ainda; então, o driver de 
terminal será incapaz de atender à solicitação. Ele envia 
uma resposta de volta imediatamente para desbloquear o 
sistema de arquivos e para informar que nenhum caracte¬ 
re está disponível, mostrado como (3) na Figura 3-37. 0 
sistema de arquivos registra o fato de que um processo está 
esperando entrada de terminal na estrutura do console em 
ttyjable e, então, dispara para obter a próxima solicita¬ 
ção para trabalhar. O shell do usuário permanece bloquea- 
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Figura 3-37 Solicitação de leitura de terminal quando nenhum caractere está 
pendente. FS é o sistema de arquivos. TTY é a tarefa de terminal. O manipulador de 
interrupções enfileira os caracteres de terminal à medida que eles são inseridos, mas é o 
manipulador de interrupções de relógio que acorda o TTY. 


do até que os caracteres requeridos cheguem naturalmen¬ 
te. 

Quando um caractere é finalmente digitado no tecla¬ 
do, isso causa duas interrupções, uma quando a tecla é 
pressionada e outra quando é liberada. Essa regra também 
se aplica a teclas modificadoras como CTRL e SHIFT, que 
não transmitem nenhum dado em si, mas ainda causam 
duas interrupções por tecla. A interrupção de teclado é IRQ 
1, e JnvintOl no arquivo de código assembly mpx386.s 
■àtinkbdjnujnt (linha 13123), que, por sua vez, chama 
scan_keyboard (linha 13432) para extrair o código da te¬ 
cla a partir do hardware do teclado. Se o código é para um 
caractere comum, ele é colocado na fila de entrada do te¬ 
clado, ibuf, se a interrupção foi gerada por uma tecla sen¬ 
do pressionada, mas é ignorado se a interrupção foi gerada 
pela liberação de uma tecla. Os códigos para teclas modifi¬ 
cadoras como CTRL e SHIFT são configurados na fila para 
os dois tipos de interrupção, mas podem ser distinguidas 
mais tarde por um bit que é ativado somente quando uma 
tecla é liberada. Note que nesse ponto os códigos recebidos 
e armazenados em ibuf não são códigos em ASCII; são sim¬ 
plesmente os códigos de varredura produzidos pelo teclado 
IBM. Kbdjmjnt. então, ativa um sinalizador, tty_events 
(parte da seção do teclado de ttyjable), chama force_ 
timeout e retorna. 

Diferentemente de algumas outras rotinas de serviço de 
interrupção, kbd_hw_int não envia uma mensagem para 
acordar para a tarefa de terminal. A chamada para force_ 
timeout é indicada pelas linhas tracejadas na figura (4). 
Essas não são mensagens. Elas configuram a variável 
ttyjimeout no espaço de endereço comum para as rotinas 
de serviço de interrupção. Na próxima interrupção de reló¬ 


gio clock_handler descobre que ttyjimeout indica que é 
hora para uma chamada a tty_wakeup (linha 11452) que, 
então, envia uma mensagem (5) para a tarefa de termi¬ 
nal. Note que embora o código-fonte para ttyjvakeup es¬ 
teja no arquivo tty_c, ele executa em resposta à interrup¬ 
ção de relógio, e assim dizemos que a interrupção de reló¬ 
gio envia a mensagem para a tarefa de terminal. Se a en¬ 
trada estiver chegando rapidamente, diversos códigos de 
caractere podem ser enfileirados dessa maneira, que é a 
razão pela qual múltiplas chamadas a force Jímeout (4) 
são mostradas na figura. 

Ao obter a mensagem de wakeup , a tarefa de terminal 
inspeciona o sinalizador tty_events para cada dispositivo 
do terminal, e, para cada dispositivo que tem o sinalizador 
configurado, chama handle_events (linha 12256). 0 si¬ 
nalizador tty_events pode sinalizar vários tipos de ativida¬ 
de (embora a mais provável seja uma entrada), de modo 
que handle_events sempre chama as funções específicas 
de dispositivo tanto para a entrada como para a saída. Para 
a entrada do teclado, isso resulta em uma chamada a 
kb_read (linha 13165), que monitora códigos de teclado 
que indicam pressionamento ou liberação das teclas CTRL, 
SHIFT e ALT e convertem códigos de teclado em códigos 
ASCII. Kb_read, por sua vez, chama in Jorocess (linha 
12367), que processa os códigos ASCII, levando em conta 
caracteres especiais e sinalizadores diferentes que podem 
ser configurados, incluindo se 0 modo canônico está em 
efeito. 0 efeito é normalmente adicionar caracteres à fila 
de entrada do console em ttyjable, embora alguns códi¬ 
gos, por exemplo BACKSPACE, tenham outros efeitos. Nor¬ 
malmente, também, in Jtrocess inicia 0 ecoamento dos có¬ 
digos ASCII para 0 monitor. 



176 TANENBAUM & WOODHÜLL 


Quando o número suficiente de caracteres for recebido, 
a tarefa de terminal chama o procedimento de linguagem 
assembly phys _copy para copiar os dados para o endereço 
requerido pelo shell. Essa operação também não é uma 
passagem de mensagem e, por essa razão, é mostrada por 
linhas tracejadas (6) na Figura 3-37. Mais de uma dessas 
linhas é mostrada visto que pode haver mais de uma ocor¬ 
rência dessa operação antes de a solicitação do usuário ser 
completamente atendida. Quando a operação é, por fim. 
completada, o driver de terminal envia uma mensagem 
para o sistema de arquivos informando que o trabalho foi 
feito (7), e o sistema de arquivos reage a essa mensagem 
enviando outra de volta ao shell para desbloqueá-lo (8). 

A definição de quando caracteres suficientes deram en¬ 
trada depende do modo do terminal. No modo canônico, 
uma solicitação está completa quando uma quebra de li¬ 
nha, um fim de linha ou um código de fim de arquivo é 
recebido, e, a fim de que o processamento adequado da 
entrada seja feito, uma linha de entrada não pode exceder 
o tamanho da fila de entrada. No modo não-canônico, uma 
leitura pode solicitar um número muito maior de caracte¬ 
res, e in_process pode precisar transferir caracteres mais 
de uma vez antes que uma mensagem seja retornada para 
o sistema de arquivos para indicar que a operação está com¬ 
pleta. 

Note que o driver de terminal copia os caracteres reais 
diretamente de seu próprio espaço de endereço para o do 
shell. Ele não vai primeiro pelo sistema de arquivos. Com 
E/S de bloco, os dados passam pelo sistema de arquivos, 
permitindo manter um cache dos blocos utilizados mais 
recentemente. Se acontecer de um bloco requerido estar 
no cache, a solicitação poderá ser satisfeita diretamente pelo 
sistema de arquivos, sem fazer qualquer E/S de disco 

Para E/S de terminal, um cache não faz nenhum senti¬ 
do. Além disso, uma solicitação do sistema de arquivos para 
um driver de disco sempre pode ser satisfeita em, no máxi¬ 
mo, algumas centenas de milissegundos, de modo que não 
há nenhum prejuízo real em fazer o sistema de arquivos 
simplesmente esperar. A E/S de terminal pode levar horas 
para completar ou pode nunca se completar (no modo ca¬ 
nônico a tarefa de terminal espera uma linha completa, e 
ela também pode esperar um longo tempo no modo não- 
canônico, dependendo das configurações de MIN e TIME). 
Assim, é inaceitável fazer o sistema de arquivos bloquear 
até que uma solicitação de entrada do terminal seja satis¬ 
feita. 

Mais tarde, pode acontecer de o usuário ter digitado 
rapidamente, e os caracteres estarem disponíveis antes de 
serem solicitados, a partir de ocorrências anteriores dos 
eventos 4 e 5. Nesse caso, os eventos 1, 2,6,7 e 8 acontecem 
em rápida sucessão depois da solicitação de leitura; 3 não 
ocorre de modo algum. 

Se acontecer de a tarefa de terminal estar executando 
no momento de uma interrupção de relógio, nenhuma 
mensagem poderá ser enviada para ela porque ela não es¬ 
tará esperando. Entretanto, para manter entrada e saída 
fluindo bem quando a tarefa de terminal está ocupada, os 


sinalizadores ttyjevents para todos dispositivos terminais 
são inspecionados em várias outras ocasiões, por exemplo, 
imediatamente depois de processar e de responder uma 
mensagem. Assim, os caracteres podem ser adicionados à 
fila de console sem a ajuda de uma mensagem de wakeup 
do relógio. Se duas ou mais interrupções de relógio ocorre¬ 
rem antes de o driver de terminal terminar o que está fa¬ 
zendo, todos os caracteres são armazenados em ibuf e 
ttyjlags é repetidamente ativado. Por fim, a tarefa de ter¬ 
minal recebe uma mensagem; o restante é perdido. Mas 
como todos os caracteres são armazenados em segurança 
no buffer, nenhuma entrada digitada é perdida. É até pos¬ 
sível que no momento em que uma mensagem for recebi¬ 
da pela tarefa de terminal a entrada esteja completa e uma 
resposta já tenha sido enviada para o processo de usuário. 

0 problema do que fazer em um sistema de mensagens 
não -bufferizado (princípio àorendez-vous) quando uma 
rotina de interrupção quer enviar uma mensagem para um 
processo que está ocupado é inerente a esse tipo de projeto. 
Para a maioria dos dispositivos, como discos, as interrup¬ 
ções ocorrem somente em resposta a comandos emitidos 
pelo driver, então, somente uma interrupção pode estar 
pendente em qualquer instante. Os único dispositivos que 
geram interrupções por si mesmos são o relógio e os termi¬ 
nais (e quando ativada, a rede). O relógio é tratado con¬ 
tando-se os tiques pendentes, de modo que se a tarefa de 
relógio não receber uma mensagem da interrupção de re¬ 
lógio, ela pode compensar mais tarde. Os terminais são tra¬ 
tados fazendo a rotina de interrupções acumular os carac¬ 
teres em um buffer e ativar um sinalizador para indicar 
que caracteres foram recebidos. Se a tarefa de terminal es¬ 
tiver executando, ela verifica todos esses sinalizadores an¬ 
tes de ir dormir e adia ir dormir se houver mais trabalho a 
fazer. 

A tarefa de terminal não é acordada diretamente pela 
interrupção de terminal devido ao excessivo overhead a que 
isso levaria. 0 relógio envia uma interrupção à tarefa de 
terminal no próximo tique após cada interrupção de ter¬ 
minal. A 100 palavras por minuto, um datilógrafo digita 
menos de 10 caracteres por segundo. Mesmo com um dati¬ 
lógrafo rápido, a tarefa de terminal provavelmente recebe¬ 
rá uma mensagem de interrupção para cada caractere di¬ 
gitado no teclado, embora algumas dessas mensagens pos¬ 
sam ser perdidas. Se o buffer encher antes de ser esvaziado, 
caracteres em excesso são descartados, mas a experiência 
demonstra que, para o teclado, um buffer de 32 caracteres 
é adequado. No caso de outros dispositivos de entrada, ta¬ 
xas de transmissão de dados mais altas são prováveis — 
taxas 1.000 ou mais vezes mais rápidas que as de um dati¬ 
lógrafo são possíveis a partir de uma porta serial conectada 
a um modem de 28.800bps. A essa taxa, aproximadamente 
48 caracteres podem ser recebidos pelo modem a cada ti¬ 
que do relógio, mas para permitir compactação de dados 
na ligação do modem a porta serial conectada ao modem 
deve ser capaz de tratar pelo menos duas vezes mais. Para 
linhas seriais, o MINIX oferece um buffer de 1024 caracte¬ 
res. 
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Lamentamos que a tarefa de terminal não possa ser 
implementada sem algum compromisso com os princípi¬ 
os gerais do nosso projeto, mas o método que utilizamos 
faz o trabalho sem muita complexidade adicional no sof¬ 
tware e nenhuma perda de desempenho. A alternativa ób¬ 
via, jogar fora o princípio do rendez-vous e fazer o sistema 
armazenar todas as mensagens enviadas para destinos que 
não as estão esperando, é muito complicada e também mais 
lenta. 

Projetistas de sistema reais frequentemente defrontam- 
se com o dilema entre utilizar o caso geral, que é elegante 
o tempo todo, mas utiliza técnicas relativamente lentas, e 
utilizar técnicas que são normalmente rápidas, mas em 
um ou dois casos exigem truques para fazê-las funcionar 
adequadamente. A experiência é realmente a única orien¬ 
tação para determinar qual abordagem é melhor sob cer¬ 
tas circunstâncias. Uma considerável experiência em pro¬ 
jetos de sistemas operacionais é resumida por Lampson 
(1984) e Brooks (1975). Embora antigas, tais referências 
ainda são clássicas. 

Completaremos nossa visão geral da entrada de termi¬ 
nal resumindo os eventos que ocorrem quando a tarefa de 
terminal é ativada pela primeira vez por uma solicitação 
de leitura e quando é ativada depois de receber entrada do 
teclado (veja a Figura 3-38). No primeiro caso, quando a 
mensagem vem à tarefa de terminal solicitando caracteres 
do teclado, o procedimento principal, ttyjask (linha 
11817), chama do_read (linha 11891) para tratar a soli¬ 


citação. Do_read armazena os parâmetros da chamada na 
entrada do teclado em ttyjable, no caso de haver um nú¬ 
mero insuficiente de caracteres armazenado para satisfa¬ 
zer a solicitação. 

Ela, então, di&ma injransfer (linha 12303) para ob¬ 
ter qualquer entrada que esteja em espera, e handle_ermts 
(linha 12256) que, por sua vez, chama kbjead (linha 
13165) e injransfer mais uma vez, para tentar alimentar 
0 fluxo de entrada com mais alguns caracteres. Kb_read 
chama vários outros procedimentos não mostrados na Fi¬ 
gura 3-38 para realizar seu trabalho. O resultado é que 
qualquer coisa que esteja imediatamente disponível é co¬ 
piada para 0 usuário. Se nada estiver disponível, nada é 
copiado. Se a leitura for completada por injransfer ou 
por bandle_events. a mensagem será enviada para 0 siste¬ 
ma de arquivos quando todos os caracteres forem transfe¬ 
ridos; então, 0 sistema de arquivos pode desbloquear 0 pro¬ 
cesso chamador. Se a leitura não se completar (nenhum 
caractere ou caracteres insuficientes) do_read informa de 
volta 0 sistema de arquivos, dizendo-lhe que deve suspen¬ 
der 0 chamador original, ou, se uma leitura não-bloquea- 
dora foi solicitada, cancelar a leitura. 

O lado direito da Figura 3-38 resume os eventos que 
ocorrem quando a tarefa de terminal é acordada subse- 
qüentemente a uma interrupção de teclado. Quando um 
caractere é digitado, 0 procedimento de interrupção 
kbjowjnt (linha 13123) coloca 0 código do caractere re¬ 
cebido no buffer de teclado, ativa um sinalizador para iden- 



Figura 3-38 Tratamento de entrada no driver de terminal. O caminho do ramo esquerdo da árvore é tomado para processar uma 
solicitação de leitura de caracteres. O do ramo direito e' tomado quando uma mensagem “caractere foi digitado” é enviada para 0 driver. 
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tificar que o dispositivo de console sofreu um evento e, en¬ 
tão, determina que um tempo-limite ocorra no próximo 
tique do relógio. A tarefa de relógio envia uma mensagem 
à tarefa de terminal informando que algo aconteceu. Ao 
receber essa mensagem, ttyjask verifica os sinalizadores 
de eventos de todos os dispositivos de terminal e chama 
handle_event para cada dispositivo com um sinalizador 
levantado. No caso do teclado, handle_event chama 
kb_read e injransfer, assim como foi feito na recepção 
da solicitação de leitura original. Os eventos mostrados no 
lado direito da figura podem ocorrer várias vezes, até que 
caracteres suficientes sejam recebidos para atender a soli¬ 
citação aceita por do_read depois da primeira mensagem 
do sistema de arquivos. Se esse tenta iniciar uma solicita¬ 
ção para mais caracteres do mesmo dispositivo antes de a 
primeira solicitação estar completa, um erro é retornado. 
Cada dispositivo, naturalmente, é independente; uma soli¬ 
citação de leitura em nome de um usuário em um termi¬ 
nal remoto é processada separadamente da solicitação para 
um usuário no console. 

As funções não mostradas na Figura 3-38 que são cha¬ 
madas por kb_read incluem map_key, que converte os 
códigos de teclas (códigos de varredura) gerados pelo har¬ 
dware em códigos ASCII, make_break, que monitora o es¬ 
tado das teclas modificadoras como a tecla SHIFT, e 
in_process, que trata complicações como tentativas por 
parte do usuário de utilizar backspace para corrigir um 
erro, outros caracteres especiais e opções disponíveis em 
diferentes modos de entrada. In Jjrocess também chama 
echo (linha 12531) para que os caracteres digitados sejam 
exibidos na tela. 

Saída de Terminal 

Em geral, a saída de console é mais simples que a en¬ 
trada de terminal, pois o sistema operacional está no con¬ 
trole e não precisa preocupar-se com solicitações de saída 
chegando em momentos inconvenientes. Ademais, como o 
console do MINIX é um dispositivo mapeado em memória, 
a saída para o console é particularmente simples. Nenhu¬ 
ma interrupção é necessária: a operação básica é copiar 
dados de uma região da memória para outra. Por outro 
lado, todos os detalhes do gerenciamento da exibição, in¬ 
cluindo tratamento de seqüências de escape, devem ser tra¬ 
tadas pelo software do driver. Como fizemos com a entrada 
de teclado na seção anterior, acompanharemos as etapas 
envolvidas no envio de caracteres para o monitor do con¬ 
sole. Vamos supor, neste exemplo, que a escrita é feita no 
monitor ativo: complicações menores causadas por conso¬ 
les virtuais serão discutidas mais tarde. 

Quando um processo quer imprimir algo, geralmente 
chama printf. Printf chama write para enviar uma men¬ 
sagem para o sistema de arquivos. A mensagem contém 
um ponteiro para os caracteres a serem impressos (não os 
próprios caracteres). 0 sistema de arquivos, então, envia 
uma mensagem para o driver de terminal, que os busca e 


copia-os para a RAM de vídeo. A Figura 3-39 mostra os pro¬ 
cedimentos principais envolvidos na saída. 

Quando uma mensagem vem à tarefa de terminal soli¬ 
citando escrever na tela, do_write (linha 11964) é chama¬ 
da para armazenar os parâmetros na estrutura tty do con¬ 
sole em ttyjable. Então, handle_events (a mesma fun¬ 
ção chamada sempre que o sinalizador tty_events é en¬ 
contrado ligado) é chamada. Em cada chamada, essa fun¬ 
ção chama as rotinas de entrada e saída para o dispositivo 
selecionado em seu argumento. No caso do monitor do con¬ 
sole, isso significa que qualquer entrada de teclado que es¬ 
teja esperando é processada primeiro. Se houver entrada 
esperando, os caracteres a serem ecoados são adicionados 
a quaisquer caracteres que já estão esperando saída. En¬ 
tão, é feita uma chamada a cons_write (linha 13729), o 
procedimento de saída para monitores de memória mape¬ 
ada. Esse procedimento utiliza phys_copy para copiar blo¬ 
cos de caracteres do processo de usuário para um buffer 
local, possivelmente repetindo esse e os passos seguintes 
algumas vezes, uma vez que o buffer local armazena so¬ 
mente 64 bytes. Quando o buffer local está cheio, cada byte 
de 8 bits é transferido para outro buffer, ramqueue. Essa é 
uma matriz de palavras de 16 bits. Bytes alternados são 
preenchidos com o valor atual do byte de atributo de tela, 
que determina as cores de primeiro e de segundo planos e 
outros atributos. Quando possível, os caracteres são trans¬ 
feridos diretamente para ramqueue, mas certos caracte¬ 
res, como os de controle ou aqueles que são partes de se¬ 
qüências de escape, necessitam de tratamento especial. Tra¬ 
tamento especial também é requerido quando a posição de 
tela de algum caractere excede a largura da tela ou quan¬ 
do não há mais espaço em ramqueue. Nesses casos, 
outjehar (linha 13809) é chamada para transferir os ca¬ 
racteres e executar qualquer ação adicional necessária. Por 
exemplo, scroll_screen (linha 13896) é chamada quando 
uma quebra de linha é recebida enquanto se está endere¬ 
çando a última linha da tela, eparse_escape trata caracte¬ 
res durante uma seqüência de escape. Normalmente 
out_char chama flush (linha 13951) que copia o conteú¬ 
do de ramqueue para a memória de vídeo, utilizando a 
rotina de linguagem assemblymem_vid_copy. Flush tam¬ 
bém é chamada depois de o último caractere ser transferi¬ 
do para ramqueue, a fim de certificar-se de que toda saída 
armazenada foi exibida. O resultado final de flusb é co¬ 
mandar o chip da controladora de vídeo 6845 para exibir o 
cursor na posição correta. 

Logicamente, os bytes buscados do processo de usuário 
poderiam ser gravados na RAM de vídeo um a cada itera¬ 
ção do laço. Entretanto, acumular os caracteres em ram¬ 
queue e, então, copiar o bloco com uma chamada a 
mem_vid_copy é mais eficiente no ambiente de memória 
protegida em processadores da classe Pentium. Interessan- 
temente, essa técnica foi introduzida nas primeiras versões 
do MINIX que executavam em processadores mais antigos 
sem memória protegida. O precursor de mem_vid_copy 
lidava com um problema de sincronização — com moni- 
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Figura 3-39 Principais procedimentos utilizados na saída de terminal. A linha tracejada indica 
caracteres copiados diretamente para ramqueue por cons_write. 


tores de vídeo mais antigos, a cópia na memória de vídeo 
tinha de ser feita quando a tela era limpa durante o retraço 
vertical do feixe do CRT para evitar gerar lixo visual em 
toda a tela. 0 MlNIX não oferece mais esse suporte para equi¬ 
pamento obsoleto uma vez que a penalidade no desempe¬ 
nho é muito grande. Entretanto, a versão moderna do Mi- 
Nix beneficia-se, de outras maneiras, de copiar ramqueue 
como um bloco. 

A RAM de vídeo disponível para um console é delimita¬ 
da na estrutura console pelos campos c_start e c_limit. A 
posição atual do cursor é armazenada nos campos 
c_column e cjrow. A coordenada (0, 0) está no canto su¬ 
perior esquerdo da tela, que é onde o hardware começa a 
preencher a tela. Cada varredura de vídeo começa no en¬ 
dereço dado por c_org e continua por 8 x 25 caracteres 
(4.000 bytes). Em outras palavras, o chip 6845 puxa a pa¬ 
lavra no deslocamento c_org da RAM de vídeo e exibe o 
byte do caractere no canto superior esquerdo, utilizando o 
byte de atributo para controlar a cor, intermitência, etc. 
Então, ele busca a próxima palavra e exibe o caractere em 
(1, 0). Esse processo continua até que chegar a (79, 0), 
momento em que ele inicia a segunda linha na tela, na 
coordenada (0,1). 


Quando o computador é iniciado pela primeira vez, a 
tela é limpa, a saída é gravada na RAM de vídeo iniciando 
na posição c _start, e a c_org é atribuído o mesmo valor 
que a c_start. Assim, a primeira linha aparece na linha 
superior da tela. Quando a saída deve ir para uma nova 
linha, seja porque a primeira linha está cheia seja porque 
um caractere de nova linha é detectado por out_char. a 
saída é gravada na posição dada por c_start mais 80. Por 
fim, todas as 25 linhas são preenchidas, e a rolagem da 
tela é necessária. Alguns programas, editores, por exem¬ 
plo, exigem rolar para baixo também, quando o cursor está 
na linha superior e é necessário mover-se mais para cima 
no texto. 

Há duas maneiras como a rolagem da tela pode ser ge¬ 
renciada. Na rolagem por software, o caractere a ser exi¬ 
bido na posição (0, 0) está sempre na primeira posição na 
memória do vídeo, a palavra 0 relativamente à posição 
apontada por c_start, e o chip da controladora de vídeo é 
comandado para exibir essa posição primeiro mantendo o 
mesmo endereço em c_org. Quando a tela for rolada, o 
conteúdo da posição relativa 80 na RAM de vídeo, o come¬ 
ço da segunda linha na tela, é copiado para a posição rela¬ 
tiva 0. A palavra 81 é copiada para a posição relativa 1 e 
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assim por diante. A seqüência da varredura permanece inal¬ 
terada, colocando os dados da posição 0 da memória na 
posição (0, 0) da tela, e a imagem na tela parece ter-se 
movido para cima uma linha. O custo é que a CPU moveu 
80 x 24 = 1920 palavras. Na rolagem por hardware, os 
dados não são movidos na memória; em vez disso, 0 chip 
da controladora de vídeo é instruído a iniciar a exibição 
em um ponto diferente, por exemplo, com os dados na pa¬ 
lavra 80. A contabilidade é feita adicionando 80 ao conteú¬ 
do de c_org, salvando-o para futura referência e gravando 
esse valor no registrador correto do chip da controladora 
de vídeo. Isso requer que a controladora seja suficiente¬ 
mente inteligente para referenciar a RAM de vídeo de modo 
circular, pegando os dados do início da RAM (0 endereço 
em c_start ) quando alcança 0 fim (0 endereço em 
cjimit), ou que a RAM de vídeo tenha mais capacidade 
que simplesmente as 80 x 2.000 palavras necessárias para 
armazenar uma única tela do monitor. Adaptadoras de ví¬ 
deo mais antigas geralmente têm memória menor, mas são 
capazes de acessar a RAM de tal modo e fazer a rolagem 
por hardware. A maioria das novas adaptadoras geralmen¬ 
te tem muito mais memória que necessitaria para exibir 
uma única tela de texto, mas as controladoras não são ca¬ 
pazes de referência circular. Assim, uma adaptadora com 
32768 bytes de memória de exibição pode armazenar 204 
linhas completas de l60 bytes cada e pode fazer 0 rolagem 
por hardware 179 vezes antes de a incapacidade de refe¬ 
rência circular tornar-se um problema. Mas, por fim, uma 
operação de cópia de memória será necessária para mover 
os dados das últimas 24 linhas de volta à posição na me¬ 
mória do vídeo. Qualquer que seja 0 método utilizado, uma 
linha de espaços é copiada para a RAM de vídeo para asse¬ 
gurar que a nova linha no fundo da tela esteja vazia. 

Quando consoles virtuais são configurados, a memória 
disponível dentro de um adaptador de vídeo é dividida igual¬ 
mente entre 0 número de consoles desejado por meio da 
adequada inicialização dos campos c_start e cjimit para 
cada console. Isso tem um efeito sobre a rolagem. Em qual¬ 
quer adaptador suficientemente grande para suportar con¬ 
soles virtuais, a rolagem por software acontece de vez em 
quando mesmo que a rolagem por hardware esteja em uso. 
Quanto menor a quantidade de memória disponível para 
cada monitor de console, mais freqüentemente a rolagem 


por software deve ser utilizada. O limite é alcançado quan¬ 
do 0 máximo número possível de consoles é configurado. 
Então, cada operação de rolagem é uma operação de rola¬ 
gem por software. 

A posição do cursor em relação ao início da RAM de 
vídeo pode ser derivada de c_column e c_row, mas é mais 
rápido armazená-la explicitamente (em c_cur). Quando 
um caractere é impresso, é colocado na RAM de vídeo na 
posição c_cur. a qual é, então, atualizada, assim como 
c_column. A Figura 3-40 resume os campos da estrutura 
console que afetam a posição atual e a origem da exibição. 

Os caracteres que afetam a posição do cursor (p. ex., 
quebra de linha, backspace) são tratados ajustando-se os 
valores de column_c, c_row e c_cur. Esse trabalho é feito 
no final de Jlush por uma chamada a setj5845, 0 qual 
configura os registradores no chip da controladora de ví¬ 
deo. 

O driver de terminal suporta seqüências de escape para 
permitir que editores de tela e outros programas interati¬ 
vos atualizem a tela de uma maneira flexível. As seqüênci¬ 
as suportadas são um subconjunto de um padrão ANSI e 
devem ser adequadas para permitir que muitos programas 
escritos para outro hardware e para outros sistemas opera¬ 
cionais sejam facilmente portados para MINIX. Há duas ca¬ 
tegorias de seqüências de escape: aquelas que nunca con¬ 
têm um parâmetro variável e aquelas que podem conter 
parâmetros. Na primeira categoria, 0 único representante 
suportado pelo MINIX é ESC M, que indexa inversamente a 
tela, movendo 0 cursor para cima uma linha e rolando a 
tela para baixo se 0 cursor já estiver na primeira linha. A 
outra categoria pode ter um ou dois parâmetros numéri¬ 
cos. Todas as seqüências nesse grupo começam com ESC [. 
O “[” é 0 introdutor de seqiiência de controle. Uma 
tabela das seqüências de escape definidas pelo padrão de 
ANSI e reconhecidas pelo MINIX foi mostrada na Figura 3- 
36. 

O processamento das seqüências de escape não é trivi¬ 
al. Seqüências de escape válidas no MINIX podem ser tão 
curtas quanto dois caracteres, como em ESC M, ou até 8 
caracteres no caso de uma seqüência que aceita dois parâ¬ 
metros numéricos que podem, cada um, ter um valor de 
dois dígitos como em ESC [20;60H, que move o cursor para 
a linha 20, coluna 60. Em uma seqüência que aceita um 


Campo 

Significado 

c_start 

Início da memória de vídeo para esse console 

cjimit 

Limite da memória de vídeo para esse console 

c_column 

Coluna atual (0-79) com 0 à esquerda 

c_row 

Fila atual (0-24) com 0 no topo 

c_cur 

Deslocamento na RAM de vídeo para 0 cursor 

c_org 

Posição na RAM apontada pelo registrador de base do 6845 


Figura 3-40 Os campos fora a estrutura de console que relaciona à posição atual de tela. 
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parâmetro, o parâmetro pode ser omitido e, em uma se- 
qüência que aceita dois parâmetros, qualquer um ou am¬ 
bos podem ser omitidos. Quando um parâmetro é omitido 
ou quando é utilizado um que está fora do limite válido, 
ele é substituído pelo padrão. O padrão é o valor válido 
mais baixo. 

Considere as seguintes maneiras como se poderia cons¬ 
truir uma seqüência para mover-se para o canto superior 
esquerdo da tela: 

1. ESC [H é aceitável, porque se nenhum parâmetro 
for dado os parâmetros válidos mais baixos são 
assumidos. 

2. ESC [1; 1H enviará corretamente o cursor para a 
linha 1 e a coluna 1 (com ANSI, os números de 
linha e de coluna iniciam em 1). 

3. Tanto ESC [1; H como ESC [; 1H têm um parâme¬ 
tro omitido, o que conduz ao padrão 1 como no 
primeiro exemplo. 

4. ESC [0;0H fará o mesmo, uma vez que sendo cada 
parâmetro inferior ao valor mínimo válido, o mí¬ 
nimo é utilizado no lugar. 

Esses exemplos são apresentados não para sugerir que 
se deve deliberadamente utilizar parâmetros inválidos, mas 
para mostrar que o código que analisa sintaticamente es¬ 
sas seqüências não é trivial. 

O MINIX implementa uma máquina de estados finitos 
para fazer essa análise sintática. A variável c_esc_state na 
estrutura console normalmente tem um valor de 0. Quan¬ 
do out_char detecta um caractere ESC, ela muda 
c_esc_state para 1, e os caracteres subseqüentes são pro¬ 
cessados por parse_escape (linha 13986). Se o próximo ca¬ 
ractere for o introdutor de seqüência de controle, o estado 
2 é iniciado; caso contrário, a seqüência é considerada com¬ 
pleta e do_escape (linha 14045) é chamada. No estado 2, 
contanto que os caracteres que entram sejam numéricos, 
um parâmetro é calculado multiplicando-se o valor ante¬ 
rior do parâmetro (inicialmente 0) por 10 e adicionando o 
valor numérico do caractere atual. Os valores dos parâme¬ 
tros são mantidos em uma matriz e, quando um ponto-e- 
vírgula é detectado, o processamento muda para a próxi¬ 
ma célula na matriz. (A matriz no mintx tem somente dois 
elementos, mas o princípio é o mesmo). Quando um ca¬ 
ractere não-numérico que não é um ponto-e-vírgula é en¬ 
contrado, a seqüência é considerada completa e do_escape 
é chamada. O caractere atual na entrada para do_escape, 
então, é utilizado para eleger exatamente que ação tomar 
e como interpretar os parâmetros, sejam os padrões ou se¬ 
jam aqueles entrados no fluxo de caracteres. Isso é ilustra¬ 
do na Figura 3-48. 

Mapas de Teclado Carregáveis 

0 teclado IBM PC não gera códigos ASCII diretamente. 
As teclas são identificadas individualmente com um nú¬ 
mero, iniciando com as teclas que estão localizadas no can¬ 


to esquerdo superior do teclado original do PC —1 para a 
tecla “ESC”, 2 para o “ 1" e assim por diante. A cada tecla é 
atribuído um número, incluindo as teclas modificadoras 
como a tecla SHIFT da esquerda e tecla SHIFT da direita, 
numeradas como 42 e 54. Quando uma tecla é pressiona¬ 
da, o MiNix recebe o número da tecla como um código de 
varredura. Um código de varredura também é gerado quan¬ 
do uma tecla é liberada, mas o código gerado na liberação 
da tecla tem o bit mais significativo ligado (equivalente a 
adicionar 128 ao número da tecla). Assim, as ações de pres¬ 
sionar e de liberar uma tecla podem ser distinguidas. Mo¬ 
nitorando quais teclas modificadoras foram pressionadas 
e ainda não foram liberadas, um grande número de com¬ 
binações é possível. Para propósitos normais, naturalmen¬ 
te, combinações de duas teclas, como SHIFT-A ou CTRL-D, 
são bem gerenciáveis para pessoas que digitam com as duas 
mãos, mas para ocasiões especiais são possíveis combina¬ 
ções de três teclas (ou mais), por exemplo, CTRL-SHIFT-A 
ou a bem-conhecida combinação CTRL-ALT-DEL que os 
usuários de PC reconhecem como a maneira de reiniciali¬ 
zar o sistema. 

A complexidade do teclado de PC permite muita flexibi¬ 
lidade na maneira como ele é utilizado. Um teclado-pa- 
drão tem 47 teclas normais de caractere definidas (26 alfa¬ 
béticas, 10 numéricas e 11 de pontuação). Se quisermos 
utilizar três combinações de teclas modificadoras, como 
CTRL-ALT-SHIFT, podemos suportar um conjunto de carac¬ 
teres de 376 (8 x 47) elementos. Esse não é de modo algum 
o limite do que é possível, mas, por enquanto, vamos supor 
que não queremos distinguir entre as teclas modificadoras 
da direita e as da esquerda, nem utilizar o teclado numéri¬ 
co nem qualquer tecla de função. De fato, não somos limi¬ 
tados a utilizar somente as teclas CTRL, ALT e SHIFT como 
modificadoras; poderíamos separar algumas teclas do con¬ 
junto de teclas usuais e utilizá-las como modificadoras se 
quisermos escrever um driver que suporte tal sistema. 

Os sistemas operacionais que utilizam esses teclados 
utilizam um mapa de teclado para determinar qual códi¬ 
go de caractere passar para um programa com base na te¬ 
cla que está sendo pressionada e as teclas modificadoras 
em efeito. O mapa de teclado do MINIX logicamente é uma 
matriz de 128 linhas, representando possíveis valores de 
código de varredura (esse tamanho foi escolhido para sa¬ 
tisfazer aos teclados japoneses; teclados norte-americanos 
e europeus não têm tantas teclas) e 6 colunas. As colunas 
representam nenhuma tecla modificadora, a tecla de SHIFT, 
a tecla Control, a tecla ALT esquerda, a tecla ALT direita e 
uma combinação de qualquer uma das teclas ALT com a 
tecla de SHIFT. Há, portanto, 720 ((128 - 6) x 6) códigos de 
caractere que podem ser gerados por esse esquema, dado 
um teclado adequado. Isso requer que cada entrada na ta¬ 
bela seja uma quantidade de 16 bits. Para teclados dos EUA 
as colunas ALT e ALT2 são idênticas. ALT2 é nomeada AL- 
TGR em teclados para outros idiomas, e muitos desses ma¬ 
pas de teclado suportam teclas com três símbolos, utilizan¬ 
do essa tecla como um modificador. 
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Um mapa de teclado-padrão (determinado pela linha 
#include keymaps/us-std.src 

em keyboard. c) é compilado no kernel do MINIX em tempo 
de compilação, mas uma chamada 

ioctlfO, KIOCSMAP, keymap) 

pode ser utilizada para carregar um mapa diferente no ker¬ 
nel a partir do endereço keymap. Um mapa de teclado com¬ 
pleto ocupa 1536 bytes (128 x 6 x 2). Mapas de teclado 
extras são armazenados em uma forma compactada. Um 
programa chamado genmap é utilizado para fazer um novo 
mapa de teclado compactado. Quando compilado, genmap 
inclui 0 código keymap.src para um mapa de teclado par¬ 
ticular; então, 0 mapa é compilado dentro de genmap. Nor¬ 
malmente, genmap é executado imediatamente depois de 
ser compilado, momento em que ele dá saída à versão com¬ 
pactada para um arquivo e, então, 0 executável genmap e' 
excluído. 0 comando loadkeys lê um mapa de teclado com¬ 


pactado, expande-o internamente e, então, chama IOCTL 
para transferir 0 mapa do teclado para a memória do ker¬ 
nel. O MINIX pode executar loadkeys automaticamente ao 
iniciar, e 0 programa também pode ser invocado pelo usu¬ 
ário em qualquer momento. 

0 código-fonte para um mapa de teclado define uma 
grande matriz inicializada e, a fim de economizar espaço, 
um arquivo de mapa de teclado não é impresso com 0 có¬ 
digo-fonte. A Figura 3-41 mostra na forma de tabela 0 con¬ 
teúdo de algumas linhas desrc/kernel/keymaps/usstd.src 
para ilustrar vários aspectos dos mapas de teclado. Não há 
nenhuma tecla no teclado IBM PC que gere um código de 
varredura 0. A entrada para 0 código 1, a tecla ESC, mostra 
que 0 valor retornado é inalterado quando a tecla de SHIFT 
ou a tecla CTRL é pressionada, mas que um código dife¬ 
rente é retornado quando uma tecla ALT é pressionada si¬ 
multaneamente com a tecla ESC. Os valores compilados 
nas várias colunas são determinados por macros definidas 
tminclude/minix/keymap.h: 


#define C(c) ((c) & 0x1 F) /* 

#define A(c) ((c) 10x80) /* 

#define CA(c) A(C(c)) /* 

#define L(c) ((c) | HASCAPS) /* 


Mapeia para o código de control */ 

Liga oito bits (ALT) */ 

CTRL-ALT */ 

Adiciona 0 atributo “Caps Lock ativado” */ 


As primeiras três dessas macros manipulam bits no có¬ 
digo do caracter entre aspas para produzir 0 código neces¬ 
sário a ser retornado para 0 aplicativo. A última liga 0 bit 
HASCAPS no byte alto do valor de 16 bits. Isso é um sinali¬ 
zador que indica que 0 estado da variável capslock precisa 
ser verificado, e 0 código possivelmente modificado antes 
de retornar. Nas figuras, as entradas para códigos de varre¬ 
dura 2,13 e 16 mostram como típicas teclas numéricas, de 
pontuação e alfabéticas são tratadas. Para 0 código 28, um 
recurso especial é visto — normalmente a tecla ENTER 
produz um código CR (OxOD), representado aqui como 
C('M’). Como 0 caractere de nova linha em arquivos UNIX 
é 0 código LF (OxOA) e, às vezes, é necessário entrar com 


isso diretamente, esse mapa de teclado oferece uma com¬ 
binação de CTRL-ENTER, que produz esse código, C(‘J'). 

0 código de varredura 29 é um dos códigos modifica¬ 
dores e deve ser reconhecido independentemente da outra 
tecla que é pressionada; então, 0 valor de CTRL é retornado 
indiferentemente de qualquer outra tecla que possa ser pres¬ 
sionada. As teclas de função não retornam valores ASCII 
normais, e a linha para 0 código de varredura 59 mostra 
simbolicamente os valores (definidos em include/minix/ 
keymap.h ) que são retornados para a tecla F1 em combi¬ 
nação com outros modificadores. Esses valores são Fl: 
0x0110, SF1: 0x1010, AF1: 0x0810, ASF1: OxOClO e CF1: 
0x0210. A última entrada mostrada na figura, para 0 códi- 


Código de varredura 

Caracter 

Normal 

Shift 

ALT1 

ALT2 

ALT+SHIFT 

CTRL 

00 

nenhum 

0 

0 

0 

0 

0 

0 

01 

ESC 

C(T) 

C(T) 

CA(T) 

CA(’D 

CA(T) 

C(T) 

02 

'1' 

T 

T 

A(T) 

A(T) 

A(T) 


13 

V 

’=’ 

V 

A('=’) 

A(’=’) 

A(V) 


16 

’q’ 

L(’q’) 

’Q’ 


A('q’) 

A(’Q') 


28 

CFl/LF 

C(’M’) 

C('M’) 

CA('M') 

CA('M') 

CA(’M’) 

MMM 

29 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

CTRL 

59 

Fl 

Fl 

SF1 

AF1 


ASF1 


127 

??? 

0 

0 

0 

0 

0 

0 


Figura 3-41 Algumas entradas de um arquivo-fonte de mapa de teclado. 
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go de varredura 127, é típica de muitas entradas próximas 
do fim da matriz. Para muitos teclados, certamente a mai¬ 
oria dos utilizados na Europa e nas Américas, não há te¬ 
clas suficientes para gerar todos os possíveis códigos e essas 
entradas na tabela são preenchidas com zero. 

Fontes Carregáveis 

Os primeiros PCs tinham os padrões para gerar carac¬ 
teres em uma tela de vídeo armazenados somente em ROM, 
mas os monitores utilizados em sistemas modernos ofere¬ 
cem RAM nos adaptadores de vídeo na qual padrões perso¬ 
nalizados para o gerador de caracteres podem ser carrega¬ 
dos. Isso é suportado pelo MINIX com uma operação IOCTI. 

ioctl (0, TIOCSFON, font) 

0 MINIX suporta um modo de vídeo de 80 colunas x 25 li¬ 
nhas, e os arquivos de fonte contêm 4096 bytes. Cada byte 
representa uma linha de 8 pixels que é iluminada se o va¬ 
lor do bit é 1, e 16 dessas linhas são necessárias para mape¬ 
ar cada caractere. Entretanto, o adaptador de vídeo utiliza 
32 bytes para mapear cada caractere, oferecendo resolução 
mais alta em modos atualmente não-suportados pelo mi- 
NIX. O comando loadfont é oferecido para converter esses 
arquivos na estrutura font de 8192 bytes referenciada pela 
chamada IOCTL e utiliza essa chamada para carregar a fon¬ 
te. Como com os mapas de teclado, uma fonte pode ser 
carregada em tempo de inicialização ou em qualquer tem¬ 
po durante operação normal. Entretanto, cada adaptador 
de vídeo tem uma fonte-padrão embutida em sua ROM que 
está disponível por padrão. Não há nenhuma necessidade 
de compilar uma fonte no próprio minix, e o único suporte 
de fonte necessário no kernel é o código para executar a 
operação IOCTL TIOCSFON. 

3-9-4 Implementação do Driver de 
Terminal Independente de Dispositivo 

Nesta seção, começaremos a ver o código-fonte do dri¬ 
ver de terminal detalhadamente. Vimos quando estudamos 
os dispositivos de bloco que múltiplas tarefas suportando 
vários dispositivos diferentes poderiam compartilhar uma 
base comum de software. O caso com os dispositivos termi¬ 
nais é semelhante, mas com a diferença de que há uma 
tarefa de terminal que suporta vários tipos diferentes de 
dispositivo terminal. Aqui começaremos com o código in¬ 
dependente de dispositivo. Em seções posteriores veremos o 
código dependente de dispositivo para o teclado e para o 
monitor de console mapeado em memória. 

Estruturas de Dados da Tarefa de 
Terminal 

O arquivo tty.h contém definições utilizadas pelos ar¬ 
quivos de C que implementam os drivers de terminal. A 


maioria das variáveis declaradas nesse arquivo é identifi¬ 
cada pelo prefixo tty_. Há também uma dessas variáveis 
declarada em glo.h como EXTERN. É ttyjimeout, que é 
utilizada pelos manipuladores de interrupções do relógio e 
do terminal 

Dentro de tty.h, as definições dos sinalizadores 
OJXOCTTYe. ojlONBLOCK (que são argumentos opcio¬ 
nais para a chamada OPEN) são duplicatas das definições 
em include/fcntl.h, mas repetidas aqui a fim de não preci¬ 
sarmos incluir outro arquivo. Os tipos devfunj e 
devfunargj (linhas 11611 e 11612 ) são utilizados para 
definir ponteiros para funções, a fim de fornecer chama¬ 
das indiretas utilizando um mecanismo semelhante ao que 
vimos no código para o laço principal dos drivers de disco. 

A definição mais importante em tty.h é a estrutura tty 
(linhas Il6l4 a 11668). Há uma estrutura dessa para cada 
dispositivo de terminal (o monitor e o teclado do console 
contam como um único tenninal). A primeira variável na 
estrutura At)’, tty_events, é o sinalizador que é ligado quando 
uma interrupção causa uma mudança que requer que a 
tarefa de terminal atenda o dispositivo. Quando esse sina¬ 
lizador é levantado, a variável global tty_timeout também 
é tratada para informar ao manipulador de interrupções 
de relógio para acordar a tarefa de terminal no próximo 
tique de relógio. 

O restante da estrutura tty é organizado para agrupar 
variáveis que lidam com entrada, com saída, com status e 
com informações sobre operações incompletas. Na seção 
de entrada, ttyjnhead e tty_intail definem a fila onde ca¬ 
racteres recebidos são armazenados. Tty_incount conta o 
número de caracteres nessa fila e tty_eotct conta linhas ou 
caracteres, como explicado a seguir. Todas as chamadas 
específicas de dispositivo são feitas indiretamente, com ex¬ 
ceção das rotinas que iniciam os terminais, que são cha¬ 
madas para configurar os ponteiros utilizados para as cha¬ 
madas indiretas. Os campos tty_devread e ttyjcancel ar¬ 
mazenam ponteiros para código específico de dispositivo 
para executar as operações de leitura e de cancelamento 
de entrada. Tty_min é utilizado em comparações com 
tty_eotct. Quando o último torna-se igual ao anterior, uma 
operação de leitura está completa. Durante uma entrada 
canônica, ttyjnin é configurado como 1 e tty_eotct conta 
as linhas entradas. Durante uma entrada não-canônica, 
tty_eotct conta caracteres e tty_min é configurado a partir 
do campo MIN da estrutura termios. A comparação das duas 
variáveis informa quando uma linha está pronta ou quan¬ 
do a contagem mínima de caracteres é alcançada, depen¬ 
dendo do modo. 

Ttyjime armazena o valor do temporizador que deter¬ 
mina quando a tarefa de terminal deve ser acordada pelo 
manipulador de interrupções de relógio e ttyjimenext é 
um ponteiro utilizado para associar em uma lista enca¬ 
deada os campos ttyjime ativos. A lista é ordenada sem¬ 
pre que um temporizador é configurado; então, o manipu¬ 
lador de interrupções de relógio somente precisa olhar na 
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primeira entrada. 0 minix pode suportar muitos terminais 
remotos, dos quais somente alguns podem ter temporiza¬ 
dores ativados em qualquer momento. A lista de tempori¬ 
zadores ativos torna o trabalho do manipulador de relógio 
mais fácil do que seria se ele precisasse verificar cada en¬ 
trada em ttyjable. 

Como o enfileiramento da saída é tratado pelo código 
específico de dispositivo, a seção de saída de tty não decla¬ 
ra nenhuma variável e consiste inteiramente de ponteiros 
para funções específicas de dispositivo que escrevem, ecoam, 
enviam um sinal de pausa e cancelam saída. Na seção 
de status os sinalizadores tty_reprint. ttyjescape e 
tty Jnhibited indicam que o último caractere visto tem um 
significado especial; por exemplo, quando um caractere 
CTRL-V (LNEXT) é visto, ttyjiscaped é configurado como 
1 indicando que qualquer significado especial do próximo 
caractere deve ser ignorado. 

A próxima parte da estrutura armazena dados sobre as 
operações DEV_READ, DEV_WRITE e DEVJOCTL em pro¬ 
gresso. Há dois processos envolvidos em cada uma dessas 
operações. O servidor que gerencia a chamada de sistema 
(normalmente o sistema de arquivos) é identificado em 
tty_ incaller (linha 11644). 0 servidor chama a tarefa tty 
em nome de outro processo que precisa fazer uma opera¬ 
ção de E/S e esse cliente é identificado em ttyjnproc (li¬ 
nha 11645). Como descrito na Figura 3-37, durante um 
READ. caracteres são transferidos diretamente da tarefa de 
terminal para um buffer dentro do espaço de memória do 
chamador original. Ttyjnproc e ttyjn_vir localizam esse 
buffer. As próximas duas variáveis, ttyjnleft e ttyjncum 
contam os caracteres ainda necessários e aqueles já trans¬ 
feridos. Conjuntos semelhantes de variáveis são necessári¬ 
os para uma chamada de sistema WRITK. Para lOCTL. pode 
haver uma transferência imediata de dados entre o proces¬ 
so solicitante e a tarefa; assim, um endereço virtual é ne¬ 
cessário, mas não há nenhuma necessidade de variáveis 
para marcar o progresso de uma operação. Uma solicita¬ 
ção ioctl pode ser adiada, por exemplo, até que a saída 
atual esteja completa, mas quando é a hora certa a solici¬ 
tação é executada em uma única operação. Por fim, a es¬ 
trutura tty inclui algumas variáveis que não entram em 
nenhuma outra categoria, incluindo ponteiros para as fun¬ 
ções para tratar as operações DEVJOCTL e ÜEVJCLOSE no 
nível de dispositivo, uma estrutura termios no estilo POSIX 
e uma estrutura winsize que oferece suporte para disposi¬ 
tivos de exibição baseados em janelas. A última parte da 
estrutura oferece armazenamento para a própria fila de en¬ 
trada na matriz ttyjnbuf. Note que essa é uma matriz de 
ul6j. não de caracteres de 8 bits. Embora aplicativos e 
dispositivos utilizem códigos de 8 bits para caracteres, a 
linguagem C requer que a função de entrada getchar fun¬ 
cione com um tipo maior de dados de modo que possa re¬ 
tornar um valor simbólico EOF além de todos os 256 possí¬ 
veis valores de byte. 

A ttyjable, uma matriz de estruturas tty, é declarada 
utilizando a macro EXTERN (linha 11670). Há um ele¬ 
mento para cada terminal ativado pelas definições 


NRjOONS, NR_RSJINESeNRJ y IYS em indude/minix/ 
config.h. Para a configuração discutida neste livro, dois 
consoles são ativados, mas o MINIX pode ser recompilado 
para adicionar até duas linhas seriais e até 64 pseudoter- 
minais. 

Há uma outra definição EXTERN em ttyj}. Ttyjimelist 
(linha II 69 O) é um ponteiro utilizado pelo temporizador 
para guardar 0 início da lista encadeada de campos 
ttyjime. O arquivo de cabeçalho tty_b é incluído em mui¬ 
tos arquivos, e 0 espaço de armazenamento para tty Jable 
e ttyjimelist é alocado durante a compilação de table.c, 
do mesmo modo como as variáveis EXTERN que são defi¬ 
nidas no arquivo de cabeçalho glo.b. 

No fim de tty.h , duas macros, buflen e bufend. são de¬ 
finidas. Essas são utilizadas freqüentemente no código da 
tarefa de terminal, que faz muitas operações de cópia de 
dados de e para os buffers. 

O Driver de Terminal Independente de 
Dispositivo 

A tarefa de terminal principal e as funções de suporte 
independentes de dispositivo estão todas em tty.h. Como a 
tarefa suporta muitos dispositivos diferentes, 0 número de 
dispositivo secundário deve ser utilizado para distinguir 
qual está sendo suportado em uma chamada particular, e 
eles são definidos nas linhas 11760 a 11764. Seguindo-se a 
isso, há algumas definições de macro. Se um dispositivo 
não é iniciado, os ponteiros para as funções específicas de 
dispositivo desses dispositivos conterão zeros colocados aí 
pelo compilador de C. Isso torna possível definir a macro 
tty_active (linha 11774) que retorna FALSE se um pontei¬ 
ro nulo é localizado. Naturalmente, 0 código de inicializa¬ 
ção para um dispositivo não pode ser acessado indireta¬ 
mente se parte de seu trabalho é inicializar os ponteiros 
que tornam 0 acesso indireto possível. Nas linhas 11777 a 
11783, estão definições de macros condicionais para equi¬ 
parar as chamadas de inicialização para dispositivos RS- 
232 ou de pseudoterminais a chamadas a uma função nula 
quando esses dispositivos não são configurados. Do_pty. 
de maneira semelhante poder ser desativado nessa seção. 
Isso torna possível omitir 0 código para esses dispositivos 
inteiramente se ele não for necessário. 

Como há tantos parâmetros configuráveis para cada 
terminal e pode haver alguns terminais em um sistema 
em rede, a estrutura termios_defaults é declarada e é ini¬ 
ciada com valores padrão (todo os quais são definidos em 
include/termios.h) nas linhas 11803 a 11810. Essaestru- 
turaé copiada para entrada ttyjable de um terminal sem¬ 
pre que é necessário inicializá-lo ou reinicializá-lo. Os pa¬ 
drões para os caracteres especiais foram mostrados na Fi¬ 
gura 3-33- A Figura 3-42 mostra os valores-padrão para os 
vários sinalizadores. Na linha seguinte, a estrutura 
winsize_defaults é declarada de maneira semelhante. Ela 
é deixada para ser inicializada com zeros pelo compilador 
C. Essa é a ação-padrão adequada; ela significa “0 tama¬ 
nho da janela é desconhecido, utilize /etc/termcap.” 
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Campo 

Valores-padrão 

cjflag 

BRKINT ICRNL IXON IXANY 

c_oflag 

OPOST ONLCR 

c_cflag 

CREAD CS8 HUPCL 

cjflag 

ISIG IEXTEN ICANON ECHO ECHOE 


Figura 3-42 Valores-padrão para os sinalizadores de termios. 


0 ponto de entrada para a tarefa de terminal é ttyjask 
(linha 11817). Antes de entrar no laço principal, uma cha¬ 
mada é feita a ttyjnit para cada terminal configurado (no 
laço na linha 11826) e, então, a mensagem de inicializa¬ 
ção do MiNix é exibida (linhas 11829 a 11831). Embora o 
código-fonte mostre uma chamada para/t/w/? quando esse 
código é compilado, a macro que converte chamadas para 
a rotina de biblioteca/>n>z//em chamadas para printk está 
em efeito. Printk utiliza uma rotina chamada/wtó dentro 
do driver de console, de modo que o sistema de arquivos 
não está envolvido. Essa mensagem vai apenas para o mo¬ 
nitor de console primário e não pode ser redirecionada. 

O laço principal nas linhas 11833 a 11884 é, a princí¬ 
pio, como o laço principal de qualquer tarefa — ele rece¬ 
be uma mensagem, executa um switch no tipo de mensa¬ 
gem para chamar a função apropriada e, então, gera uma 
mensagem de retorno. Entretanto, há algumas complica¬ 
ções. Em primeiro lugar, muito trabalho é feito por rotinas 
de interrupção de baixo nível, especialmente no tratamen¬ 
to de entrada de terminal. Na seção anterior vimos que ca¬ 
racteres individuais do teclado são recebidos e bufferiza- 
dos sem enviar uma mensagem à tarefa de terminal para 
cada caractere. Assim, antes de tentar receber uma mensa¬ 
gem, o laço principal sempre varre toda a ttyjable para 
inspecionar o sinalizador tp->tty_events de cada terminal 
e chama handle_events conforme necessário (linhas 11835 
a 11837), para cuidar dos negócios não-finalizados. So¬ 
mente quando não há nada exigindo atenção imediata é 
que uma chamada é feita para receber. Se a mensagem 
recebida é do hardware uma declaração continue provoca 
o retorno ao início do laço e a verificação de eventos é re¬ 
petida. 

Em segundo lugar, essa tarefa serve a vários dispositi¬ 
vos. Se uma mensagem recebida é de uma interrupção de 
hardware, o dispositivo ou os dispositivos que necessitam 
de serviço são identificados verificando-se os sinalizadores 
tp->tty_evmts. Se a interrupção não é uma interrupção 
de hardware, o campo TTY_LINE na mensagem é utilizado 
para determinar qual dispositivo deve responder à mensa¬ 
gem. O número de dispositivo secundário é decodificado 
por uma série de comparações, por meio das quais tp é apon¬ 
tado para a entrada correta em ttyjable (linhas 11845 até 
11864). Se o dispositivo é um pseudoterminal, do_pty 
( pty.c ) é chamada, e o laço principal é reiniciado. Nesse 
caso, do-pty gera a mensagem de resposta. Naturalmente, 
se pseudoterminais não estão ativados, a chamada a do J>ty 


utiliza a macro fictícia definida anteriormente. Pode-se 
esperar que tentativas para acessar dispositivos inexisten¬ 
tes não ocorreriam, mas é sempre mais fácil adicionar ou¬ 
tra verificação que checa se não há nenhum erro em outra 
parte no sistema. No caso de o dispositivo não existir ou de 
não estar configurado, uma mensagem de resposta com 
uma mensagem de erro ENXIO é gerada e, novamente, o 
controle retorna para o topo do laço. 

0 resto da tarefa assemelha-se ao que vimos no laço 
principal de outras tarefas, um switch no tipo de mensa¬ 
gem (linhas 11874 a 11883). A função apropriada para o 
tipo de solicitação, dojread. do_urite e assim por diante, 
é chamada. Em cada caso, a função chamada gera a men¬ 
sagem de resposta, em vez de passar ao laço principal as 
informações necessárias para criar a mensagem. Uma 
mensagem de resposta é gerada no fim do laço principal 
somente se não foi recebido um tipo válido de mensagem, 
caso em que uma mensagem de erro ENXIO é enviada. 
Como as mensagens de resposta são enviadas de muitos 
lugares diferentes dentro da tarefa de terminal, uma rotina 
comum, tty_reply, é chamada para tratar os detalhes de 
construir mensagens de resposta. 

Se a mensagem recebida por ttyjask é um tipo válido 
de mensagem, não o resultado de uma interrupção, e não 
vem de um pseudoterminal, o switch no fim do laço prin¬ 
cipal despachará uma das funções do_read. do_ urite. 
dojoctl. do-open. dojlose ou do_cancel. Os argumen¬ 
tos para cada uma dessas chamadas são tp. um ponteiro 
para uma estrutura tty. e o endereço da mensagem. Antes 
de ver cada um deles, mencionaremos algumas considera¬ 
ções gerais. Como ttyjask pode servir a múltiplos disposi¬ 
tivos terminais, essas funções devem retornar rapidamente 
para que o laço principal possa continuar. Entretanto, 
do_read. do_ urite e dojoctl podem não ser capazes de 
completar imediatamente todo o trabalho solicitado. Para 
permitir que o sistema de arquivos sirva a outra chamada, 
uma resposta imediata é exigida. Se a solicitação não pu¬ 
der ser completada imediatamente o código SUSPEND é 
retornado no campo de status da mensagem de resposta. 
Isso corresponde à mensagem marcada como (3) na Figu¬ 
ra 3-37 e suspende o processo que iniciou a chamada, en¬ 
quanto desbloqueia o sistema de arquivos. As mensagens 
correspondentes a (7) e (8) na figura serão enviadas mais 
tarde quando a operação puder ser completada. Se a solici¬ 
tação não puder ser satisfeita ou um erro ocorrer, a conta¬ 
gem de bytes transferidos ou o código de erro é retornado 
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no campo de status da mensagem de retorno para o siste¬ 
ma de arquivos. Nesse caso, uma mensagem será enviada 
imediatamente do sistema de arquivos de volta para o pro¬ 
cesso que fez a chamada original, para acordá-lo. 

Ler de um terminal é fundamentalmente diferente de 
ler de um dispositivo de disco. O driver de disco envia um 
comando para o hardware de disco e os dados acabarão 
sendo retornados, exceto no caso de uma falha mecânica 
ou elétrica. O computador pode exibir um aviso de entrada 
na tela, mas não há meio de forçar uma pessoa sentada ao 
teclado a começar a digitar. A esse respeito, não há garan¬ 
tia nem mesmo de que uma pessoa estará sentada aí. Para 
fazer o retomo rápido que é exigido, do_read (linha 11891) 
começa armazenando informação que permitirá que a so¬ 
licitação seja completada mais tarde, quando e se a entra¬ 
da chegar. Há alguma verificação de erros a ser feita pri¬ 
meiro. É um erro se o dispositivo ainda estiver esperando 
entrada para atender uma solicitação anterior ou se os pa¬ 
râmetros na mensagem são nulos (linhas 11901 a 11908). 
Se esses testes são passados, as informações sobre a solici¬ 
tação são copiadas para os campos adequados nas entra- 
dastp—>ttyjable do dispositivo nas linhas 11911 a 11915. 
O último passo, configurar tp—>tty_inleft com o número 
de caracteres exigido, é importante. Essa variável é utiliza¬ 
da para determinar quando a solicitação de leitura é satis¬ 
feita. No modo canônico, tp->tty Jnleft é decrementada 
por um para cada caractere retornado, até que um fim de 
linha seja recebido, ponto em que é repentinamente redu¬ 
zida a zero. No modo não-canônico, ela é tratada de ma¬ 
neira diferente, mas em qualquer caso ela é redefinida para 
zero sempre que a chamada é satisfeita, seja por atingir 
um tempo-limite seja obtendo pelo menos o número mí¬ 
nimo de bytes exigidos. Quando tp->tty Jnleft atinge zero, 
uma mensagem de resposta é enviada. Como veremos, 
mensagens de resposta podem ser geradas em vários luga¬ 
res. Às vezes, é necessário verificar se um processo de leitu¬ 
ra ainda espera uma resposta; um valor não-zero de tp— 
>tty Jnleft serve como um sinalizador para tal fim. 

No modo canônico, um dispositivo terminal espera en¬ 
trada até que o número de caracteres solicitados na cha¬ 
mada tenha sido recebido ou o fim de uma linha ou o fim 
do arquivo seja alcançado. O bit ICANON na estrutura ter- 
mios é testado na linha 11917 para ver se o modo canôni¬ 
co está em efeito para o terminal. Se não estiver configura¬ 
do, os valores de termios MIN e TIME são verificados para 
determinar que ação tomar. 

Na Figura 3-35, vimos como MINe TIME interagem para 
oferecer maneiras diferentes como uma chamada de leitu¬ 
ra comporta-se. TIME é testado na linha 11918. Um valor 
de zero corresponde à coluna esquerda na Figura 3-35 e, 
nesse caso, nenhum teste adicional é necessário neste pon¬ 
to. Se TIME é diferente de zero, então MIN é testado. Se é 
zero, settimer é chamada para iniciar o temporizador que 
terminará a solicitação DEV_READ após algum tempo, 
mesmo que nenhum byte seja recebido. Tp->tty_min é 
aqui configurado como 1, então, a chamada terminará ime¬ 
diatamente se um ou mais bytes forem recebidos antes de 


atingir o tempo-limite. Nesse ponto, nenhuma verificação 
quanto a uma possível entrada ainda foi feita; então, mais 
de um caractere já pode estar esperando para satisfazer a 
solicitação. Nesse caso, todos os caracteres que estiverem 
prontos, até o número especificado na chamada RF.AD, se¬ 
rão retornados logo que sej a encontrada a entrada. Se TIME 
e MIN forem diferentes de zero, o temporizador tem um 
significado diferente. O temporizador é utilizado como um 
temporizador entre caracteres nesse caso. Ele é disparado 
somente depois de o primeiro caractere ser recebido e é rei¬ 
niciado após cada caractere sucessivo. Tp- >tty_eotct conta 
caracteres no modo não-canônico e se ele é zero na linha 
11931, nenhum caractere foi recebido ainda e 0 tempori¬ 
zador entre bytes é inibido. Lock e unlock são utilizados 
para proteger essas duas chamadas para settimer, a fim de 
evitar interrupções de relógio quando settimer estiver exe¬ 
cutando. 

Em qualquer caso, na linha 11941, injransferé cha¬ 
mada para transferir quaisquer bytes já na fila de entrada 
diretamente para 0 processo de leitura. Em seguida, há uma 
chamada para handle_events, que pode colocar mais da¬ 
dos na fila de entrada e chamar injransfer novamente. 
Essa duplicação aparente de chamadas requer alguma ex¬ 
plicação. Embora a discussão até agora se tenha dado em 
termos da entrada de teclado, do_read está na parte inde¬ 
pendente de dispositivo do código e também serve a entra¬ 
das de terminais remotos conectados por linhas seriais. É 
possível que a entrada anterior tenha preenchido 0 buffer 
de entrada RS-232 até 0 ponto de a entrada ser inibida. A 
primeira chamada a injransfer não inicia 0 fluxo nova¬ 
mente, mas a chamada a bandle_events pode ter esse efei¬ 
to. O fato de que ela, então, causa uma segunda chamada 
a injransfer é somente um bônus. A coisa importante é 
certificar-se de que 0 terminal remoto tenha permissão para 
enviar novamente. Qualquer uma dessas chamadas pode 
resultar na satisfação da solicitação e no envio da mensa¬ 
gem de resposta para 0 sistema de arquivos. Tp—>tty Jnleft 
é utilizada como um sinalizador para ver se a resposta foi 
enviada; se ele é ainda diferente de zero na linha 11944, 
do_read gera e envia a mensagem de resposta. Isso é feito 
nas linhas 11949 a 11957. Se a solicitação original especi¬ 
ficou uma leitura não-bloqueadora, 0 sistema de arquivos 
é instruído a passar um código de erro EAGA1N de volta ao 
chamador original. Se a chamada é uma leitura bloquea- 
dora comum, 0 sistema de arquivos recebe um código SUS- 
PEND, desbloqueando-o, mas dizendo-lhe para deixar 0 
chamador original bloqueado. Nesse caso, 0 campo tp- 
>tty Jnrepcode do terminal é configurado como REVIVE. 
Quando e se 0 READ mais tarde for satisfeito, esse código 
será colocado na mensagem de resposta ao sistema de ar¬ 
quivos para indicar que 0 chamador original foi colocado 
para dormir e necessita ser reanimado. 

Do_write (linha 11964) é semelhante a dojead, mas 
mais simples, porque há menos opções com que se preocu¬ 
par no tratamento de uma chamada de sistema WRITE. Ve¬ 
rificações semelhantes às feitas por do_read são realiza¬ 
das para ver se uma escrita anterior ainda não está em pro- 
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gresso e quais parâmetros de mensagem são válidos e, en¬ 
tão, os parâmetros da solicitação são copiados para a es¬ 
trutura tty. Handle_events é chamada então, e pt— 
>tty_outleft é verificado para ver se o trabalho foi feito (li¬ 
nhas 11991 e 11992). Se tiver sido, uma mensagem de res¬ 
posta já foi enviada por handle_events, e não há nada a 
fazer. Caso contrário, uma mensagem de resposta é gerada 
com os parâmetros da mensagem, dependendo de a cha¬ 
mada original write ter sido feita ou não no modo não- 
bloqueador. 

A próxima função, dojoctl (linha 12012), apesar de 
longa, não é difícil de entender. O corpo de dojoctl são 
duas declarações switch. A primeira determina 0 tamanho 
do parâmetro apontado pelo ponteiro na mensagem de so¬ 
licitação (linhas 12033 a 12064). Se 0 tamanho não for 
zero, a validade do parâmetro é testada. O conteúdo não 
pode ser testado aqui, mas 0 que pode ser testado é se uma 
estrutura do tamanho necessário, começando no endereço 
especificado ajusta-se dentro do segmento especificado para 
ele estar. O restante da função é outro switch no tipo da 
operação IOCTL requerida (linhas 12075 a 12l6l) . Infeliz- 
mente, suportar as operações requeridas pelo posix com a 
chamada IOCTL significa que foi necessário inventar no¬ 
mes para operações IOCTL que sugerem, mas não dupli¬ 
cam, nomes requeridos pelo posix. A Figura 3-43 mostra 0 
relacionamento entre os nomes requeridos pelo POSIX e os 
nomes utilizados pela chamada IOCTL do MINIX. A opera¬ 
ção TCGETS serve uma chamada tcgetattr pelo usuário e 
simplesmente retorna uma cópia da estrutura tp— 
>ttyJermios do dispositivo de terminal. Os quatro tipos 
de requisição seguintes compartilham código. Os tipos de 
solicitação TCSETSW, TCSETSF e TCSETS correspondem a 
chamadas de usuário para a função definida pelo posix 
tcsetattr e todas têm a ação básica de copiar uma nova es¬ 


trutura termios para uma estrutura tty do terminal. A ope¬ 
ração de cópia é feita imediatamente para chamadas TC¬ 
SETS e pode ser feita para as chamadas TCSETSW e TCSETSF 
se a saída estiver completa, por uma dwmâ&phys_copy 
para obter os dados do usuário, seguida por uma chamada 
a setattr, nas linhas 12098 e 12099- Se tcsetattr foi chama¬ 
da com um modificador solicitando adiamento da ação 
ate' a conclusão da saída atual, os parâmetros para a solici¬ 
tação são colocados na estrutura tty do terminal para pos¬ 
terior processamento se 0 teste de tp->tty_outleft na linha 
12084 revelar que saída não está completa. Tcdrain sus¬ 
pende um programa até que a saída esteja completa e é 
traduzido em uma chamada IOCTL do tipo TCDRAIN. Se a 
saída já estiver completa, ela não tem mais nada a fazer. 
Caso contrário, ela também deve deixar as informações na 
estrutura tty. 

A função POSIX tcflush descarta dados de entrada não- 
lidos e/ou de saída não-enviados, de acordo com seu argu¬ 
mento; a tradução IOCTL é simples e direta, consistindo em 
uma chamada à função ttyjcancel que serve a todos os 
terminais, e/ou a função específica de dispositivo aponta¬ 
da por tp—>tty_ocancel (linhas 12102 a 12109). Tcflowé 
traduzido similarmente de maneira simples e direta em 
uma chamada IOCTL. Para suspender ou reiniciar a saída, 
ele configura um valor TRUE ou FALSE em tp—>tty_ 
inhibited e, então, configura 0 sinalizador tp—>tty_events. 
Para suspender ou reiniciar uma entrada, ele envia 0 códi¬ 
go apropriado STOP (normalmente CTRL-S) ou START 
(CTRL-Q) para 0 terminal remoto, utilizando a rotina es¬ 
pecífica de dispositivo de eco apontado por tp—>tty_echo 
(linhas 12120 a 12125). 

A maior parte do restante das operações tratadas por 
dojoctl é tratada em uma linha de código, chamando uma 
função apropriada. Nos casos das operações NOCSMAP (car- 


Função do POSIX 

Operação do POSIX 

Tipo do IOCTL 

Parâmetro do IOCTL 

tcdrain 

(nenhum) 

TCDFtAIN 

(nenhum) 

tcflow 

TCOOFF 

TCFLOW 

int=TCOOFF 

tcflow 

TCOON 

TCFLOW 

int=TCOON 

tcflow 

TCIOFF 

TCFLOW 

int=TCIOFF 

tcflow 

TCION 

TCFLOW 

int=TCION 

tcflush 

TCIFLUSH 

TCFLSH 

int=TCIFLUSH 

tcflush 

TCOFLUSH 

TCFLSH 

int=TCOFLUSH 

tcflush 

TCIOFLUSH 

TCFLSH 

int=TCIOFLUSH 

tcgetattr 

(nenhuma) 

TCGETS 

termios 

tcsetattr 

TCSANOW 

TCSETS 

termios 

tcsetattr 

TCSADRAIN 

TCSETSW 

termios 

tcsetattr 

TCSAFLUSH 

TCSETSF 

termios 

tcsendbreak 

(nenhuma) 

TCSBRK 

int=duração 


Figura 3-43 As chamadas do POSIX e as operações ioctl. 
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regar mapa de teclado) e TIOCSFON (carregar fonte), um 
teste é feito para certificar-se de que o dispositivo é real¬ 
mente um console, uma vez que essas operações não se 
aplicam a outros terminais. Se terminais virtuais estive¬ 
rem em utilização, o mesmo mapa de teclado e de fonte 
aplica-se a todos os consoles; o hardware não oferece qual¬ 
quer meio fácil para fazer o contrário. As operações de ta¬ 
manho de janela copiam uma estrutura winsize entre o 
processo de usuário e a tarefa de terminal. Note, entretan¬ 
to, o comentário sob o código para a operação TIOCSWINSZ. 
Quando um processo muda seu tamanho de janela, espe¬ 
ra-se que o kernel envie um sinal SIGWINCH para o grupo 
do processo em algumas versões do UNIX. 0 sinal não é 
requerido pelo posix-padrão. Mas qualquer pessoa que pen¬ 
se em utilizar essas estruturas deve considerar adicionar 
código aqui para iniciar esse sinal. 

Os últimos dois casos em dojoctl suportam as funções 
requeridas pelo POSI Xtcgetpgrp e tcsetpgrp. Não há nenhu¬ 
ma ação associada com esses casos e elas sempre retornam 
um erro. Não há nada errado com isso. Essas funções su¬ 
portam controle de jobs, a capacidade de suspender e 
reiniciar um processo a partir do teclado. 0 controle de 
jobs não é requerido pelo POSIX e não é suportado pelo mi- 
NiX. Entretanto, o POSIX requer tais funções, mesmo quan¬ 
do o controle de jobs não é suportado, para assegurar a 
portabilidade dos programas. 

Do_open (linha 12171) tem uma ação básica simples 
a executar — incrementar a variável tp->ttyjopenct do 
dispositivo para que ele possa ser verificado quanto a estar 
aberto. Entretanto, há alguns testes a serem feitos primei¬ 
ro. O POSIX especifica que para terminais normais o pri¬ 
meiro processo que abrir um terminal é o líder da sessão 
e quando um líder de sessão morre, o acesso ao terminal é 
revogado para outros processos em seu grupo. Os daemons 
devem ser capazes de gravar mensagens de erro, e se sua 
saída de erro não for redirecionada para um arquivo, ela 
deve ir para um dispositivo de exibição que não pode ser 
fechado. Para esse propósito, existe um dispositivo chama¬ 
do /dev/log no MINIX. Fisicamente é o mesmo dispositivo 
que /dev/console, mas é endereçado por um número de 
dispositivo secundário separado e tratado diferentemente. 
Trata-se de um dispositivo somente para gravação e, as¬ 
sim, do_open retorna um erro EACCESS se uma tentativa 
for feita para abri-lo para leitura (linha 12183). 0 outro 
teste feito por dojopen é testar o sinalizador 0_N0CTTY. 
Se ele não estiver ativo, e o dispositivo não for /dev/log, o 
terminal torna-se o terminal controlador para um grupo 
de processos. Isso é feito colocando o número de processo 
do processo que realizou a chamada no campo tp— 
>tty_pgrp da entrada em ttyjable. Seguindo-se a isso, a 
variável tp—>tty_openct é incrementada, e a mensagem 
de resposta é enviada. 

Um dispositivo terminal pode ser aberto mais de uma 
vez, e a próxima função, do_dose (linha 12198), não tem 
nada a fazer exceto decrementar tp—>ttyjopenct. 0 teste 


na linha 12204 frustra uma tentativa de fechar o dispositi¬ 
vo no caso de ele ser /dev/log. Se essa operação for o últi¬ 
mo fechamento, a entrada é cancelada chamando tp- 
>tty_icancel. Rotinas específicas de dispositivo apontadas 
por tp->ttyjocancel e tp->t/y_close também são chama¬ 
das. Então, vários campos na estrutura tty para o dispositi¬ 
vo são retornados aos seus valores padrão, e a mensagem 
de resposta é enviada. 

O último manipulador de tipo de mensagem é 
do_cancel (linha 12220). Esse é invocado quando um si¬ 
nal é recebido para um processo que está bloqueado, ten¬ 
tando ler ou escrever. Há três estados que devem ser verifi¬ 
cados: 

1. O processo pode estar lendo quando eliminado. 

2. O processo pode estar escrevendo quando elimina¬ 
do. 

3. O processo pode estar suspenso por tcdrain até que 
sua saída esteja completa. 

Um teste é feito para cada caso, e a rotina geral tp- 
>ttvjcancel, ou a rotina específica de dispositivo aponta¬ 
da por tp->tty_ocancel, é chamada conforme necessário. 
No último caso, a única ação necessária é desligar o sina¬ 
lizador tp->tty Joreq, indicando que a operação lOCTLestá 
completa. Por fim, o sinalizador tp—>tty_events é ativado, 
e uma mensagem de resposta é enviada. 

Código de Suporte ao Driver de Terminal 

Agora que vimos as funções de primeiro nível chama¬ 
das no laço principal de ttyjask é hora de vermos o código 
que as suporta. Iniciaremos com handle_events (linha 
12256). Como mencionado anteriormente, em cada inte¬ 
ração do laço principal da tarefa de terminal, é verificado 
o sinalizador tp->tty_events para cada dispositivo termi¬ 
nal e handle_events é chamada se o sinalizador indicar 
que é requerida atenção para um terminal em particular. 
Do_read e dojvrite também chamam bandle_events. Essa 
rotina deve trabalhar rapidamente. Ela redefine o sinali¬ 
zador tp->tty_events e, então, chama as rotinas específi¬ 
cas do dispositivo para leitura e escrita, utilizando os pon¬ 
teiros para as funções tp—>tty_devread e tp—>tty_demvnte 
(linhas 12279 para 12282). Essas são chamadas incondi¬ 
cionalmente, porque não há nenhum meio de testar se uma 
leitura ou uma gravação levantou um sinalizador - foi 
feita uma escolha de projeto aqui, que verificar dois sinali¬ 
zadores para cada dispositivo seria mais caro do que fazer 
duas chamadas cada vez que um dispositivo estivesse ati¬ 
vo. Além disso, na maior parte do tempo um caractere re¬ 
cebido de um terminal deve ser ecoado; assim, as duas cha¬ 
madas serão necessárias. Como observado na discussão 
sobre tratamento de chamadas tcsetattr por dojoctl, o PO- 
Six pode adiar operações de controle em dispositivos até 
que a saída atual esteja completa; assim o momento ime¬ 
diatamente após a chamada da função específica de dispo- 
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sitivo tty_devwrite é uma boa hora para cuidar de opera¬ 
ções ioctl. Isso é feito na linha 12285, onde dojoctl é cha¬ 
mada se houver uma solicitação de controle pendente. 

Como o sinalizador tp->tty _events é levantado por 
interrupções, e caracteres podem chegar em um fluxo rá¬ 
pido de um dispositivo rápido, há uma chance de que no 
momento em que as chamadas para as rotinas de leitura e 
de gravação específicas de dispositivo e derjoctl estejam 
completas, outras interrupções tenham levantado o sinali¬ 
zador novamente. É dada alta prioridade à tarefa de passar 
adiante uma entrada a partir do buffer onde a rotina de 
interrupção colocou-a inicialmente. Assim handle_events 
repete as chamadas às rotinas específicas de dispositivo, 
contanto que o sinalizador tp- >tty_event sej a encontrado 
levantado ao fim do laço (linha 12286). Quando o fluxo 
de entrada pára (também poderia ser de saída, mas é mais 
provável que as entradas façam exigências tão repetidas), 
injransfer é chamada para transferir caracteres da fila 
de entrada ao buffer dentro do processo que iniciou a ope¬ 
ração de leitura. A própria injransfer envia uma mensa¬ 
gem de resposta se a transferência completar a solicitação, 
seja transferindo o número máximo de caracteres requeri¬ 
do seja alcançando o fim de uma linha (no modo canôni¬ 
co). Se ela fizer isso, tp—>tty_left será zero no retorno para 
handle_ events. Aqui um outro teste é feito e uma mensa¬ 
gem de resposta é enviada se o número de caracteres trans¬ 
feridos alcançou o número mínimo requerido. Testar tp— 

>tty _ inleft previne que uma mensagem duplicada seja 

enviada. 

A seguir, veremos injransfer (linha 12303), queé res¬ 
ponsável por mover dados da fila de entrada no espaço de 
memória da tarefa para o buffer do processo de usuário 
que solicitou a entrada. Entretanto, uma cópia simples e 
direta de bloco não é possível. A fila de entrada é um buffer 
circular, e os caracteres precisam ser verificados para ver se 
o fim do arquivo não foi alcançado, ou caso o modo canô¬ 
nico esteja em efeito, se a transferência apenas continua 
através do fim de uma linha. Ademais, a fila de entrada é 
uma fila de quantidades de 16 bits, mas o buffer do desti¬ 
natário é uma matriz de caracteres de 8 bits. Assim um 
buffer local intermediário é utilizado. Os caracteres são 
verificados um por um à medida que são colocados no bu¬ 
ffer local e quando ele se enche ou quando a fila de entra¬ 
da foi esvaziada, phys_copy é chamada para mover o con¬ 
teúdo do buffer local para o buffer do processo receptor (li¬ 
nhas 12319 a 12345). 

Três variáveis na estrutura tty, tp—>ttyjnleft, tp— 
>tty_eotct e tp->tty_min, são utilizadas para decidir se 
injransfer tem qualquer trabalho a fazer, e as primeiras 
duas controlam seu laço principal. Como mencionado an¬ 
teriormente, tp->tty Jnleft é configurado inicialmente 
como o número de caracteres requeridos por uma chama¬ 
da READ. Normalmente, ele é decrementado por um, sem¬ 
pre que um caractere é transferido, mas pode ser repenti¬ 
namente reduzido a zero quando uma condição que sina¬ 
liza o fim de uma entrada é alcançada. Sempre que se tor¬ 
na zero, uma mensagem de resposta para o leitor é gerada, 


assim ela também serve como um sinalizador para indicar 
se uma mensagem foi enviada. Portanto, no teste na linha 
12314, encontrar tp—>ttyJnleft com valor zero é razão 
suficiente para abortar a execução de injransfer sem en¬ 
viar uma resposta. 

Na próxima parte do teste, p->tty_eotctetp—>tty_min 
são comparados. No modo canônico, essas duas variáveis 
referem-se a linhas de entrada completas e, no modo não- 
canônico, elas referem-se a caracteres. Tp—>tty_eotct é 
incrementada sempre que uma "quebra de linha" ou um 
byte é colocado na fila de entrada, e é decrementado por 
injransfer sempre que uma linha ou byte é removido da 
fila. Assim, ele conta o número de linhas ou de bytes que 
foram recebidos pela tarefa de terminal, mas ainda não 
passados para um leitor. Tj)—>tty_min indica o número 
mínimo de linhas (no modo canônico) ou de caracteres 
(no modo não-canônico) que devem ser transferidos para 
completar uma solicitação de leitura. Seu valor é sempre 1 
no modo canônico e pode ser qualquer valor de 0 até 
MAXJNPUT (255 no MIN1X) no modo não-canônico. A se¬ 
gunda metade do teste na linha 12314 faz com que 
injransfer retorne imediatamente no modo canônico se 
uma linha completa ainda não foi recebida. A transferên¬ 
cia não é feita até que uma linha esteja completa de modo 
que o conteúdo da fila possa ser modificado se, por exem¬ 
plo, um caractere ERASE ou um KILL for subsequentemen¬ 
te digitado pelo usuário antes de a tecla ENTER ser pressi¬ 
onada. No modo não-canônico, ocorrerá um retorno ime¬ 
diato se o número mínimo de caracteres ainda não estiver 
disponível. 

Algumas linhas mais adiante, tp—>ttyJnleft e tp- 
>tty_eotct são utilizadas para controlar o laço principal 
de injransfer. No modo canônico, a transferência conti¬ 
nua até que não reste mais uma linha completa na fila. No 
modo não-canônico, tp—>tty_eotct é uma contagem de 
caracteres pendentes. Tp—>tty_min controla se o laço é 
iniciado, mas não é utilizada para determinar quando pa¬ 
rar. Uma vez que o laço começa, todos os caracteres dispo¬ 
níveis ou o número de caracteres solicitados na chamada 
original será transferido, o que for menor. 

Os caracteres são quantidades de 16 bits na fila de en¬ 
trada. O código real do caractere a ser transferido para o 
processo de usuário está nos 8 bits inferiores. A Figura 3-44 
mostra como os bits altos são utilizados. Três são utiliza¬ 
dos para configurar um sinalizador que indica se o carac¬ 
tere foi precedido por LNEXT (CTRL-V) se significa fim de 
linha ou se representa um de vários códigos que indicam 
que uma linha esteja completa. Quatro bits são utilizados 
para uma contagem para mostrar quanto espaço de tela é 
utilizado quando o caractere é ecoado. O teste na linha 
12322 verifica se o bit IN_EOF (D na figura) está ligado. 
Isso é testado na parte superior do laço interno porque um 
fim de arquivo (CTRL-D) em si não é transferido para o 
leitor, nem é contado na contagem de caracteres. Como 
cada caractere é transferido, uma máscara é aplicada para 
zerar os 8 bits superiores e somente o valor ASCII nos 8 bits 
inferiores é transferido para o buffer local (linha 12324). 
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0 

V 

D 

N 

c 

c 

c j 

c 

7 

6 

5 

4 

3 

2 

1 

0 I 


V: IN_ESC, escapado por LNEXT (CTRL-V) 

D: AT_EOF, fim de arquivo (CTRL-D) 

N: IN_EOT, quebra de linha (NL e outros) 

cccc: contagem de caracteres ecoados 

7: Bit 7, pode ser zerado se ISTRIP estiver ligado 

6-0: Bits 0-6, código ASCII 

Figura 3-44 Os campos em um código de caractere na fila de entrada. 


Há mais uma maneira de sinalizar o fim da entrada, 
mas a rotina específica de dispositivo de entrada é que deve 
determinar se um caractere recebido é uma quebra de li¬ 
nha, CTRL-D ou outro caractere desse tipo e marcar cada 
um desses caracteres. In_transfer somente precisa testar 
quanto a essa marca, o b\UN_E0T(N na Figura 3-44), na 
linha 12340. Se isso for detectado, tp->tty_eotct é decre- 
mentado. No modo não-canônico, cada caractere e' conta¬ 
do dessa maneira à medida que é colocado na fila de en¬ 
trada e cada caractere também é marcado com o bit/N_EOT 
nesse momento, assim tp->tty_eotct conta caracteres que 
ainda não foram removidos da fila. A única diferença na 
operação do laço principal de in_transfer nos dois dife¬ 
rentes modos está localizada na linha 12343. Aqui tp- 
>tty_inleft é zerado em resposta ao fato de um caractere 
marcado como uma quebra de linha ter sido encontrado, 
mas somente se o modo canônico estiver em efeito. Por¬ 
tanto, quando o controle retorna para o topo do laço, o 
laço termina adequadamente depois de uma quebra de li¬ 
nha no modo canônico, mas quebras de linha no modo 
não-canônico são ignoradas. 

Quando o laço termina, normalmente há um buffer 
local parcialmente preenchido a ser transferido (linhas 
12347 a 12353). Então, uma mensagem de resposta é en¬ 
viada se tp->tty_inleft alcançar zero. Esse é sempre o caso 
no modo canônico, mas se o modo não-canônico estiver 
em efeito, e o número de caracteres transferido é menor 
que a solicitação completa, a resposta não é enviada. Isso 
pode ser confuso se você tiver uma memória boa para de¬ 
talhes a ponto de lembrar-se de que quando vimos chama¬ 
das para injransfer (em do_read e handle_events), o 
código seguinte à chamada a injransfer envia uma men¬ 
sagem de resposta se injransfer retornar tendo transferi¬ 
do mais do que a quantidade especificada em tp->tty_min , 
o que certamente será o caso aqui. A razão por que uma 
resposta não é feita incondicionalmente a partir de 
injransfer será vista quando discutirmos a próxima fun¬ 
ção, que chama injransfer sob um conjunto de circuns¬ 
tâncias diferentes. 

Essa próxima função é in Jrocess (linha 12367), que 
é chamada a partir do software específico de dispositivo para 
tratar o processamento comum que deve ser feito em toda 
entrada. Seus parâmetros são um ponteiro para a estrutu¬ 
ra tty do dispositivo de origem, um ponteiro para a matriz 


de caracteres de 8 bits a ser processada e uma contagem. A 
contagem é retomada para o chamador. In Jrocess é uma 
função longa, mas suas ações não são complicadas. Ela 
adiciona caracteres de 16 bits à fila de entrada que posteri¬ 
ormente é processada por injransfer. 

Há várias categorias de tratamento fornecidas por 
injransfer: 

1. Caracteres normais são adicionados à fila de en¬ 
trada, estendidos para 16 bits. 

2. Os caracteres que afetam o processamento posteri¬ 
or modificam sinalizadores para sinalizar o efei¬ 
to, mas não são colocados na fila. 

3. Os caracteres que controlam o ecoamento têm efei¬ 
to imediato sem serem colocados na fila. 

4. Os caracteres com significado especial têm códi¬ 
gos como o bit EOT adicionados ao seu byte supe¬ 
rior à medida que são colocados na fila de entra¬ 
da. 

Vejamos primeiro uma situação completamente nor¬ 
mal, um caractere comum, como “x” (código 0x78 em 
ASCII), digitado no meio de uma linha curta, sem nenhu¬ 
ma seqüência de escape em efeito em um terminal que 
está configurado com as propriedades-padrão do minix. 
Como recebido do dispositivo de entrada, esse caractere 
ocupa os bits 0 a 7 na Figura 3-44. Na linha 12385, ele 
teria seu bit mais significativo, o bit 7, redefinido para zero 
se o bit ISTRIP estivesse ligado, mas o padrão no minix é 
não limpar esse bit, permitindo que códigos completos de 
8 bits sejam entrados. De qualquer modo isso não afetaria 
nosso “x”. O padrão do MINIX é permitir processamento 
estendido da entrada; então, o teste do bit IEXTEN em tp- 
>tty Jermios.cJflag (linha 12388) é aprovado, mas os 
testes sucessivos falham sob as condições que postulamos: 
nenhum caractere de escape está em efeito (linha 12391 ), 
essa entrada não é o próprio caractere de escape (linha 
12397) e essa entrada não é o caractere REPRINT (linha 
12405). 

Os testes nas próximas várias linhas descobrem que o 
caractere de entrada não é o caractere especial J > OSIX_ 
VDISABLE, nem um CR ou um AZ. Por fim, um resultado 
positivo: o modo canônico está em efeito, o que é o padrão 
normal (linha 12424). Entretanto, nosso caractere não é 
ERASE, tampouco ele é KILL, EOF (CTRL-D), NL ou 0L ; 
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portanto, na linha 12457 ainda nada terá acontecido para 
ele. Aqui se descobre que o bit LXON foi ligado, por padrão, 
permitindo a utilização dos caracteres STOP (CTRL-S) e 
START (CTRL-Q), mas nos testes que se fazem quanto a 
estes nenhuma coincidência é encontrada. Na linha 12478, 
descobre-se que o bit /S/G, que permite a utilização dos ca¬ 
racteres INTR e QUIT, é ligado por padrão, mas novamente 
nenhuma coincidência é encontrada. 

De fato, a primeira coisa interessante que talvez acon¬ 
teça a um caractere comum ocorre na linha 12491, onde é 
feito um teste para ver se a fila de entrada já está cheia. Se 
esse fosse o caso, o caractere seria descartado neste ponto, 
uma vez que o modo canônico está em efeito, e o usuário 
não o veria ecoado na tela. (A declaração continue descar¬ 
ta o caractere, uma vez que ela faz o laço externo reinici¬ 
ar). Entretanto, como postulamos condições completamen¬ 
te normais para esse exemplo, vamos supor que o buffer 
não está cheio ainda. O próximo teste, para verificar se pro¬ 
cessamento especial no modo não-canônico é necessário 
(linha 12497), falha, causando um salto para frente até a 
linha 12512. Aqui echo é chamada para exibir 0 caractere 
para 0 usuário, uma vez que 0 bit ECHO em tp- 
>tty Jermios.cJflag está ligado por padrão. 

Por fim, nas linhas 12515 a 12519, 0 caractere é utili¬ 
zado sendo colocado no fim da fila de entrada. Dessa vez 
tp—>tty_incount é incrementado, mas como este é um 
caractere comum, não é marcado pelo bit EOT, e tp~ 
>tty_eotct não é alterado. 

A última linha no laço chama injransfer se 0 carac¬ 
tere recém-transferido lotar a fila. Entretanto, sob as con¬ 
dições normais que postulamos para esse exemplo, 
injransfer não faria nada, mesmo se chamada, uma vez 
que (supondo que a fila foi servida normalmente, e a en¬ 
trada anterior foi aceita quando a linha de entrada anteri¬ 
or estava completa) tp->tty_eotct é zero, tp—>tty_min é 
1 e 0 teste no início de in_transfer (linha 12314) causa 
um retorno imediato. 

Tendo passado por in_process com um caractere co¬ 
mum sob condições normais, voltemos agora ao início de 
in_process e vejamos 0 que acontece em circunstâncias 
menos normais. Primeiro, veremos 0 caractere de escape, 
que permite que um caractere que normalmente tem um 
efeito especial seja passado para 0 processo de usuário. Se 
um caractere de escape está em efeito, 0 sinalizador tp- 
>fíy_escaped é ativado e quando isso é detectado (na li¬ 
nha 12391) 0 sinalizador é desligado imediatamente e 0 
bit INJiSC, bit V na Figura 3-44 é adicionado ao caractere 
atual. Isso causa processamento especial quando 0 carac¬ 
tere é ecoado — caracteres de controle precedidos por es¬ 
cape são exibidos como “ A ”mais 0 caractere para torná- 
los visíveis. 0 bit IN_ESC também impede que 0 caractere 
seja reconhecido por testes para caracteres especiais. As pró¬ 
ximas poucas linhas processam 0 próprio caractere de es¬ 
cape, 0 caractere LNEXT (CTRL-V por padrão). Quando 0 
código LNEXTé detectado, 0 sinalizador tp->tty _escaped 
é ligado e rawecho é chamada duas vezes para dar saída a 
um “ A ” seguido de um backspace. Isso lembra 0 usuário 


ao teclado de que um escape está em efeito e quando 0 
caractere seguinte for ecoado, ele sobrescreverá 0 “ A ”. 0 
caractere LNEXT é um exemplo de caractere que afeta os 
caracteres seguintes (nesse caso, somente 0 próximo ca¬ 
ractere) . Ele não é colocado na fila, e 0 laço reinicia depois 
das duas chamadas para rawecho. A ordem desses dois tes¬ 
tes é importante, tornando possível entrar 0 próprio carac¬ 
tere LNEXTàu 2 s vezes em uma linha, para passar a segun¬ 
da cópia para um processo. 

O próximo caractere especial processado por in_process 
é 0 caractere REPRINT (CTRL-R). Quando ele é encontra¬ 
do, é feita uma chamada a reprint (linha 12406), 0 que 
faz com que a saída ecoada atualmente seja exibida nova¬ 
mente. O próprio REPRINT, então, é descartado sem ne¬ 
nhum efeito sobre a fila de entrada. 

Entrar nos detalhes do tratamento de cada caractere 
especial seria tedioso, e 0 código-fonte de in Jprocess é sim¬ 
ples e direto. Mencionaremos somente mais alguns pon¬ 
tos. Um é que a utilização de bits especiais no byte superior 
do valor de 16 bits colocado na fila de entrada torna fácil 
identificar uma classe de caracteres que têm efeitos seme¬ 
lhantes. Assim, EOT (CTRL-D), LFe 0 caractere alternativo 
de EOL (indefinido por padrão) são marcados pelo bit EOT, 
0 bit D na Figura 3-44 (linhas 12447 a 12453), facilitando 
posterior reconhecimento. Por fim, justificaremos 0 com¬ 
portamento peculiar de injransfer observado anterior¬ 
mente. Uma resposta não é gerada cada vez que ela termi¬ 
na, apesar de, nas chamadas a injransfer que vimos an¬ 
teriormente, parecer que uma resposta sempre seria gera¬ 
da ao retomo. Lembre-se de que a chamada a injransfer 
feita por in Jrocess quando a fila de entrada está cheia 
(linha 12522) não tem nenhum efeito quando 0 modo ca¬ 
nônico está em efeito. Mas se 0 processamento não-canô- 
nico é desejado, cada caractere é marcado com 0 bit EOT 
na linha 12499 e assim cada caractere é contado por tp— 
>tty_eotct na linha 12519- Por outro lado, isso causa en¬ 
trada no laço principal de injransfer quando ela é cha¬ 
mada por causa de uma fila de entrada cheia no modo 
não-canônico. Em ocasiões assim em que nenhuma men¬ 
sagem deve ser enviada no término injransfer, é provável 
que haja mais caracteres lidos depois de retornar para 
in Jirocess. De fato, embora no modo canônico a entrada 
para um único READ seja limitada pelo tamanho da fila de 
entrada (255 caracteres no MINIX), no modo não-canônico 
uma chamada READ é capaz de entregar 0 número de ca¬ 
racteres J > OSTX_SIZE_MA/X requerido pelo POSIX. Seu va¬ 
lor no MINIX é 32767. 

As próximas funções em tty.c suportam a entrada de 
caracteres. Echo (linha 12531) trata alguns caracteres de 
uma maneira especial, mas, em geral, eles são simples¬ 
mente exibidos na porção de saída do mesmo dispositivo 
utilizado para a entrada. A saída de um processo pode estar 
indo para um dispositivo ao mesmo tempo que a entrada 
está sendo ecoada, 0 que torna as coisas confusas se 0 usu¬ 
ário ao teclado tentar backspace. Para lidar com isso, 0 

sinalizador tp->tty _ reprint sempre é configurado como 

TRUE pelas rotinas específicas de dispositivo de saída quan- 
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do é produzida saída normal, de modo que a função cha¬ 
mada para tratar um backspace pode informar que a saída 
misturada foi produzida. Como echo também utiliza as ro- 
tinas de dispositivo de saída, o valor atual de tp— 
>ttyjreprint é conservado durante o ecoamento. utilizan¬ 
do a variável local rp (linhas 12552 a 12585). Entretanto, 
se uma nova linha de entrada tiver acabado de começar, rp 
é configurado como FALSE em vez de assumir o valor anti¬ 
go, o que assegura que tp—>tty _ reprint será redefinido 

quando echo terminar. 

Você pode ter notado que echo retorna um valor, por 
exemplo, na chamada na linha 12512 em in_process 

ch = echo (tp, ch) 

O valor retornado por echo contém o número de espaços 
utilizados na tela para exibição do eco, que podem ser até 
oito se o caractere for um TAB. Essa contagem é colocada 
no campo cccc na Figura3-44. Caracteres normais ocupam 
um espaço na tela, mas se um caractere de controle (outro 
que não TAB. NL ou CR) ou um DEL (0x7F) for ecoado, ele 
será exibido como um " A ”mais um caractere ASCII im- 
primível e ocupará duas posições na tela. Por outro lado 
NL ou CR ocupam zero espaços. 0 eco real é feito por uma 
rotina específica de dispositivo, naturalmente, e sempre que 
um caractere deve ser passado para o dispositivo, uma cha¬ 
mada indireta é feita, utilizando tp—>tty_echo, como, por 
exemplo, na linha 12580, para caracteres normais. 

A próxima função, rawecho. é utilizada para pular o 
tratamento especial feito por echo. Ela verifica se o sinali¬ 
zador ECHO está ligado e, se estiver, envia o caractere para 
a rotina específica de dispositivo tp->tty_echo sem qual¬ 
quer processamento especial. Uma variável local rp é utili¬ 
zada aqui para impedir que a própria chamada de rawe¬ 
cho à rotina de saída altere o valor de tp->tty jreprint. 

Quando um backspace é encontrado por in_process. a 
próxima função, backover (linha 12607) é chamada. Ela 
manipula a fila de entrada para remover o elemento ante¬ 
riormente no início da fila se retroceder for possível — se 
a fila estiver vazia ou se o último caractere for uma quebra 
de linha, então retroceder não é possível. Aqui o sinaliza¬ 
dor tp->tty_reprint mencionado nas discussões sobre echo 
e rawecho é testado. Se for TRUE, reprint será chamada 
(linha 12618) para por uma cópia limpa da linha de saída 
na tela. Então, o campo len do último caractere exibido (o 
campo cccc da Figura 3-44) é consultado para descobrir 
quantos caracteres precisam ser excluídos no monitor, e 
para cada caractere uma seqüência de caracteres backspa- 
ce-espaço-backspace é enviada por rawecho para remo¬ 
ver o caractere indesejável da tela. 

Reprint é a próxima função. Além de ser chamada por 
backover. ela pode ser invocada pelo usuário ao pressionar 
a tecla REPRINT (CTRL-R). 0 laço nas linhas 12651 a 
12656 pesquisa para trás pela fila de entrada quanto a últi¬ 
ma quebra de linha. Se for localizada na última posição 
preenchida, não há nada a fazer e ela retorna. Caso con¬ 
trário, ecoa 0 CTRL-R, que aparece no monitor como a 
seqüência de dois caracteres “ A R” e, então, move-se para 


a próxima linha e exibe novamente a fila desde a última 
quebra de linha até 0 fim. 

Agora chegamos em out Jrocess (linha 12677). Como 
in_process, ela é chamada por rotinas específicas de dis¬ 
positivo de saída, mas é mais simples. Ela é chamada pelas 
rotinas específicas de dispositivo para RS-232 e pseudoter- 
minais, mas não pela rotina de console. OutJrocess tra¬ 
balha sobre um buffer circular de bytes mas não os remove 
do buffer. A única alteração feita na matriz é inserir um 
caractere CR à frente de um caractere NL no buffer se os 
bits OPOST (ativar processamento de saída) e ONLCR (ma¬ 
pear NL para CR-NL) em tp->tty Jermios.oflag estiverem 
ligados. Esses dois bits estão ligados por padrão no MIXIX. 
Seu trabalho é manter atualizada a variável tp->tty_ 
position na estrutura tty do dispositivo. Tabulações e ba¬ 
ckspace complicam a vida. 

A próxima rotina é devjoctl (linha 12763/ Suporta 
dojoctl ao executar a função tcdrain e a função tcsetattr 
quando é chamada com a opção TCSADRAIN ou com a op¬ 
ção TCSAFLUSH. Nesses casos, dojoctl não pode completar 
a ação imediatamente se a saída estiver incompleta; então, 
as infonnações sobre a solicitação são armazenadas nas par¬ 
tes da estrutura tty reservadas para operações IOCTL com 
atraso. Sempre que handle_erents executa, ela verifica 0 
campo tp->ttyJoreq depois de chamar a rotina específica 
de dispositivo de saída e chama devjoctl se uma operação 
estiver pendente. Dei'Joctl testa tp—>tty_outleft para ver 
se a saída está completa e, se estiver, executa as mesmas 
ações que dojoctl teria executado imediatamente se não 
tivesse havido nenhum retardo. Para servir tcdrain, a úni¬ 
ca ação é redefinir 0 campo tp->ttyJoreq e enviar a men¬ 
sagem de resposta para 0 sistema de arquivos, dizendo-lhe 
para acordar 0 processo que fez a chamada original. A vari¬ 
ante TCSAFLUSH de tcsetattr chama ttyjcancel para can¬ 
celar a entrada. Para ambas as variantes de tcsetattr. a es¬ 
trutura termios cujo endereço foi passado na chamada ori¬ 
ginal para IOCT1. é copiada para estrutura tp->ttyJermios 
do dispositivo. Setattr é, então, chamada, sucedida, como 
com tcdrain, pelo envio de uma mensagem de resposta para 
acordar 0 chamador original bloqueado. 

Setattr (linha 12789/ é 0 próximo procedimento. Como 
vimos, ela é chamada por dojoctl ou devjoctl para mu¬ 
dar os atributos de um dispositivo de terminal e por dojclose 
para redefinir os atributos de volta às configurações-pa¬ 
drão. Setattr é sempre chamada depois de copiar uma nova 
estrutura termios para a estrutura tty de um dispositivo, 
porque meramente copiar os parâmetros não é suficiente. 
Se 0 dispositivo está sendo controlado agora no modo não- 
canônico, a primeira ação é marcar todos os caracteres atu¬ 
almente na fila de entrada com 0 bit INJLOT, como teria 
sido feito quando esses caracteres originalmente foram 
entrados na fila se 0 modo não-canônico estivesse em efei¬ 
to então. É mais fácil simplesmente ir adiante e fazer isso 
(linhas 12803 a 12809) do que testar se os caracteres já 
têm 0 bit configurado. Não há nenhuma maneira de saber 
quais atributos simplesmente foram mudados e quais ain¬ 
da mantêm seus valores antigos. 
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A próxima ação é verificar os valores MIN e TIME. No 
modo canônico tp—>tty_min é sempre 1; isso é configura¬ 
do na linha 12818. No modo não-canônico, a combinação 
dos dois valores permite quatro modos de operação diferen¬ 
tes, como vimos na Figura 3-35. Nas linhas 12823 a 12825, 
tp->tty_min é primeiro configurado com o valor passado 
em tp->ttyJermiso.cc[VMIN], que, então, é modificado 
se for zero e se tp->ttyJermiso.cc [VTIME] não for zero. 

Por fim, setattr certifica-se de que a saída não está pa¬ 
rada se o controle XON/XOFF estiver desativado, envia um 
sinal d eSIGHUP se a taxa de saída estiver configurada como 
zero e faz uma chamada indireta à rotina específica de dis¬ 
positivo apontada por tp->ttyJoctl para fazer o que so¬ 
mente pode ser feito no nível de dispositivo. 

A próxima função, ttyjreply (linha 12845) foi menci¬ 
onada muitas vezes na discussão precedente. Sua ação é 
absolutamente simples e direta: construir uma mensagem 
e enviá-la. Se por alguma razão a resposta falhar, um sinal 
de pânico é emitido. As funções seguintes são igualmente 
simples. Sigchar (linha 12866) solicita que o MM envie um 
sinal. Se o sinalizador NOFLSH não estiver ativo, a fila de 
entrada será removida — a contagem de linhas ou de ca¬ 
racteres recebidos é zerada, e os ponteiros para o fim e para 
o início da fila são igualados. Essa é a ação-padrão. Quan¬ 
do um sinal SIGHUP está para ser capturado, NOFLSH pode 
ser ligado, para permitir que a entrada e a saída sejam man¬ 
tidas depois de capturar o sinal. Ttyjcancel (linha 12891) 
incondicionalmente descarta entradas pendentes da ma¬ 
neira como descrito para sigchar e, além disso, chama a 
função específica de dispositivo apontada por tp— 
>tty Jcancel, para cancelar qualquer entrada que possa 
existir no próprio dispositivo ou que esteja armazenada tem¬ 
porariamente no código de baixo nível. 

Tty_init (linha 12905) é chamada uma vez para cada 
dispositivo quando ttyjask inicia pela primeira vez. Ela 
configura padrões. Inicialmente, um ponteiro para 
tty_devnop, uma função fictícia que não faz nada, é asso¬ 
ciado às variáveis tp—>tty_icancel, tp—>tty_ocancel, tp— 
>tty_ioctl e tp—>tty_close. Tty_init. então, chama uma 
função de inicialização específica de dispositivo para a ca¬ 
tegoria apropriada de terminal (console, linha serial ou 
pseudoterminal). Essas configuram os ponteiros reais para 
funções específicas de dispositivo chamadas indiretamen¬ 
te. Lembre-se de que se não há absolutamente nenhum 
dispositivo configurado em uma categoria em particular, 
uma macro que retorna imediatamente é criada, assim 
nenhuma parte do código para um dispositivo não-confi- 
gurado precisa ser compilada. A chamada a scr_in.it inici¬ 
aliza o driver de console e também chama a rotina de ini¬ 
cialização para o teclado. 

Ttyjvakeup (linha 12929), embora curta, é extrema¬ 
mente importante no funcionamento da tarefa de termi¬ 
nal. Sempre que o manipulador de interrupções de relógio 
executa, isto é, a cada tique do relógio, a variável global 
ttyjimeout (definida em glo.h na linha 5032) é verifica¬ 
da para ver se contém um valor menor do que o tempo 
presente. Se tiver, tty_wakeup é chamada. Ttyjimeout é 


configurado como zero pelas rotinas de serviço de inter¬ 
rupção para drivers de terminal, assim wakeup é forçada 
a executar no próximo tique do relógio depois de qualquer 
interrupção de dispositivo de terminal. Ttyjimeout tam¬ 
bém é alterada por settimer quando um dispositivo de ter¬ 
minal está servindo uma chamada rkad no modo não-ca- 
nônico e precisa definir um limite de tempo como veremos 
brevemente. Quando ttyjvakeup executa, ela primeiro 
desativa o próximo wakeup. atribuindo TIME_NEVER, um 
valor muito distante no futuro, a ttyjimeout. Então, ela 
varre a lista encadeada de valores de temporizadores, que é 
ordenada com os tempos para wakeups mais próximos pri¬ 
meiro, até que ela chega a um que é posterior ao tempo 
atual. Esse é o próximo wakeup e ele é colocado em 
ttyjimeout. Tty_wakeup também configura#)->#)'_;?»>? 
para esse dispositivo como 0, o que assegura que a próxi¬ 
ma leitura será bem-sucedida mesmo que nenhum byte 
seja recebido, ativa o sinalizador tp->tty_min para o dis¬ 
positivo a fim de assegurar que ela receba atenção quando 
a tarefa de terminal executar em seguida e remove o dispo¬ 
sitivo da lista de temporizadores. Por fim, ela chama inter- 
rupt para enviar a mensagem de wakeup à tarefa. Como 
mencionado na discussão sobre a tarefa de relógio, 
ttyjjuakeup é logicamente parte do código de serviço de 
interrupções de relógio, uma vez que ela é chamada so¬ 
mente a partir daí. 

A próxima função, settimer (linha 12958) configura 
temporizadores para determinar quando retornar de uma 
chamada read no modo não-canônico. Ela é chamada com 
os parâmetros tp. um ponteiro para uma estrutura tty, e 
on, um inteiro que representa TRUE ou FALSE. Primeiro, a 
lista encadeada das estruturas tty apontadas por timelist é 
varrida, buscando uma entrada existente que coincide com 
o parâmetro tp. Se for encontrado algum, ele é removido 
da lista (linhas 12968 a 12973). Se settimer é chamada 
para encerrar um temporizador, isso é tudo que ela deve 
fazer. Se é chamada para definir um temporizador, o ele¬ 
mento tp—>ttyjime na estrutura tty do dispositivo é con¬ 
figurado como o tempo atual mais o incremento em déci¬ 
mos de segundo especificado no valor TIME da estrutura 
termios do dispositivo. Então, a entrada é colocada na lis¬ 
ta, que é mantida ordenada. Por fim, o limite de tempo 
que acabou de ser colocado na lista é comparado com o 
valor em ttyjimeout global, e esta última é substituída se 
o novo limite de tempo for mais próximo. 

Por fim, a última definição em tty.c é tty_devnop (li¬ 
nha 12992 ) é uma função de “nenhuma operação” a ser 
indiretamente endereçada onde um dispositivo não requer 
um serviço. Vimos tty_devnop utilizada em ttyjnit como 
0 valor-padrão atribuído a vários ponteiros de função antes 
de chamar a rotina de inicialização para um dispositivo. 

3.9.5 Implementação do Driver de 
Teclado 

Agora nós voltamos para 0 código dependente de dispo¬ 
sitivo que suporta 0 console do MINIX, que consiste em um 
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teclado IBM PC e em um dispositivo de exibição mapeado 
em memória. Os dispositivos físicos que os suportam são 
inteiramente separados: em um sistema desktop padrão, o 
vídeo utiliza uma placa adaptadora (da qual há pelo me¬ 
nos meia dúzia de tipos básicos) conectada à placa-mãe, 
enquanto o teclado é suportado por circuitos que fazem 
parte da placa-mãe, que fazem a interface com um com¬ 
putador de 8 bits de um único chip dentro da unidade de 
teclado. Os dois subdispositivos requerem suporte de sof¬ 
tware inteiramente separado, que está localizado nos ar¬ 
quivos keyboard. c e console, c. 

0 sistema operacional vê o teclado e o console como 
partes do mesmo dispositivo /dev/console. Se houver me¬ 
mória suficiente disponível no adaptador de vídeo, suporte 
para consoles virtuais pode ser compilado, e além de / 
dev/console pode haver dispositivos lógicos adicionais, / 
dev/ttycl, / dev/ttyc2 e assim por diante. A saída de apenas 
um console vai para o vídeo em um dado momento, e há 
somente um teclado a utilizar para entrada em qualquer 
que seja o console que esteja ativo. Logicamente, o teclado 
é subserviente ao console, mas isso é manifestado apenas 
de duas maneiras relativamente menores. Primeiro, 
ttyjable contém uma estrutura tty para o console, e onde 
campos separados são oferecidos para entrada e saída, por 
exemplo, os campos tty_devread e tty__devurite, ponteiros 
para funções em keyboard.c e console.c são preenchidos 
em tempo de inicialização. Entretanto, há somente um 
campo tty_priv e ele aponta para as estruturas de dados do 
console somente. Em segundo lugar, antes de entrar em 
seu laço principal, ttyjask chama cada dispositivo lógico 
uma vez para inicializá-lo. A rotina chamada para /dev/ 
console está em console.c. e o código de inicialização para 
o teclado é chamado a partir daí. Entretanto, essa hierar¬ 
quia implícita poderia igualmente ser invertida. Até agora 
vimos primeiro a entrada antes da saída ao lidar com dis¬ 
positivos de E/S e continuaremos seguindo esse padrão, 
discutindo keyboard.c nesta seção e deixando a discussão 
sobre console.c para a seção seguinte. 

Keyboard.c começa, como a maioria dos arquivos-fon¬ 
te que vimos, com várias declarações #include. Uma des¬ 
sas, porém, é incomum. 0 arquivo keymaps/us-std.src (in¬ 
cluído na linha 13014) não é um cabeçalho comum; é um 
arquivo-fonte de C que resulta na compilação de um mapa 
de teclado-padrão dentro de keyboard.o como uma matriz 
inicializada. O arquivo fonte do mapa de teclado não é in¬ 
cluído nas listagens no fim do livro devido ao seu tama¬ 
nho, mas algumas entradas representativas são ilustradas 
na Figura 3-41. Seguindo-se a esse #include, vêm macros 
para definir várias constantes. O primeiro grupo é utiliza¬ 
do em interação de baixo nível com a controladora de te¬ 
clado. Muitos desses são endereços de portas de E/S ou com¬ 
binações de bit que têm significado nessas interações. O 
grupo seguinte inclui nomes simbólicos para teclas especi¬ 
ais. A macro kb_addr (linha 13041) sempre retorna um 
ponteiro para o primeiro elemento da matriz kbjines, uma 
vez que o hardware IBM suporta somente um teclado. Na 
próxima linha, o tamanho do buffer de entrada do teclado 


é simbolicamente definido como KB_IN_B)TES, com um 
valor de 32. As próximas 11 variáveis são utilizadas para 
armazenar vários estados que devem ser lembrados ade¬ 
quadamente para interpretar o pressionamento de uma 
tecla. Eles são utilizados de maneiras diferentes. Por exem¬ 
plo, o valor do sinalizador capslock (linha 13046) é alter¬ 
nado entre TRUE e FALSE cada vez que a tecla CAPS LOCK 
é pressionada. O sinalizador shift (linha 13054) é configu¬ 
rado como TRUE quando a tecla Shift é pressionada e como 
FALSE quando a tecla Shift é liberada. A variável esc é con¬ 
figurada quando um código de varredura escape é recebi¬ 
do. Ele é sempre zerado na recepção do caractere seguinte. 

A estrutura kb_s nas linhas 13060 a 13065 é utilizada 
para monitorar códigos de varredura à medida que eles 
são entrados. Dentro dessa estrutura, os códigos são arma¬ 
zenados em um buffer circular na matriz ibuf. de tama¬ 
nho KBJNJSYTES. \Smam 2 Amkb_lines{NR_CONS\ des¬ 
sas estruturas é declarada, uma por console, mas de fato 
somente o primeiro é utilizado, uma vez que a macro 
kb_addr é sempre utilizada para determinar o endereço 
do kb_s atual. Entretanto, normalmente referenciamos as 
variáveis dentro dekbjines[0] utilizando um ponteiro para 
a estrutura, por exemplo, kb->ihead } para consistência 
com a maneira como tratamos os outros dispositivos e para 
tornar as referências no texto consistentes com aquelas na 
listagem do código-fonte. Uma quantidade pequena de 
memória é desperdiçada por causa dos elementos não-uti- 
lizados da matriz naturalmente. Entretanto, se alguém fa¬ 
bricar um PC com suporte de hardware para múltiplos te¬ 
clados, o MINIX está pronto; somente uma modificação da 
macro kbaddr é requerida. 

Map_ke\'0 (linha 13084) é definida como uma macro. 
Ela retorna o código ASCII que corresponde a um código 
de varredura, ignorando modificadores. Isso é equivalente 
à primeira coluna (sem shift) na matriz do mapa de tecla¬ 
do. Seu grande irmão é map_key (linha 13091), que exe¬ 
cuta o mapeamento completo de um código de varredura 
para um código ASCII, incluindo contabilização de (múl¬ 
tiplas) teclas modificadoras que são pressionadas ao mes¬ 
mo tempo que as teclas normais. 

A rotina de serviço de interrupção de teclado é 
kbdjuvjnt (linha 13123), chamada sempre que uma 
tecla é pressionada ou é liberada. Ela chama scan_ 
kevboard para obter o código de varredura do chip da con¬ 
troladora de teclado. O bit mais significativo do código de 
varredura é ligado quando a liberação de uma tecla causa 
a interrupção e, nesse caso, a tecla é ignorada a menos que 
seja uma das teclas modificadoras. Se a interrupção é cau¬ 
sada pelo pressionamento de qualquer tecla ou pela libe¬ 
ração de uma tecla modificadora, o código de varredura 
bruto é colocado no buffer circular se houver espaço, o si¬ 
nalizador tp->tty_events para o console atual é levanta¬ 
do (linha 13154) e, então Jorcejimeou té chamada para 
certificar-se de que a tarefa de relógio inicie a tarefa de 
terminal no próximo tique de relógio. A Figura 3-45 mos¬ 
tra códigos de varredura no buffer para uma curta linha de 
entrada que contém dois caracteres em caixa alta, cada 
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Figure 3-45 Códigos de varredura no buffer de entrada, com as correspondentes teclas pressionadas embaixo, para uma linha de 
texto inserida no teclado. L+, L-, R+ e R- representam, respectivamente, pressionar e liberar as teclas Shift esquerda e direita. O código 
para uma liberação de tecla é 128 mais o código para o pressionamento da mesma tecla. 


um precedido pelo código de varredura para pressionamen¬ 
to de uma tecla Shift e seguido pelo código para a liberação 
da tecla Shift. 

Quando a interrupção de relógio ocorre, a própria tare¬ 
fa de terminal executa e, ao encontrar o sinalizador tp- 
>tty_events do dispositivo de console ligado, ela chama 
kb_read (linha 13165), a rotina específica de dispositivo, 
utilizando o ponteiro no campo tp->tty_devread da es¬ 
trutura tty do console. Kb_read pega códigos de varredura 
do buffer circular do teclado e coloca códigos ASCII em seu 
buffer local, que é suficientemente grande para armaze¬ 
nar as seqüências de escape que devem ser geradas em res¬ 
posta a algum código de varredura do teclado nume'rico. 
Fda, então, chama in_process no código independente do 
hardware para colocar os caracteres na fila de entrada. Nas 
linhas 13181 a 13183, lock e unlock são utilizados para 
proteger o decremento de kb—>icount de uma possível in¬ 
terrupção de teclado, chegando ao mesmo tempo. A cha¬ 
mada para make_break retorna o código ASCII como um 
inteiro. Teclas especiais, como as do teclado numérico e as 
teclas de função, têm valores maiores que OxFF neste pon¬ 
to. Os códigos na faixa de HOMEaINSRT (0x101 a OxlOC, 
definidas em include/minix/keymap.h) resultam de pres¬ 
sionar o teclado numérico e são convertidos em seqüênci¬ 
as de escape de 3 caracteres, mostradas na Figura 3-4, uti¬ 


lizando a matriz numpad_map. As seqüências, então, são 
passadas para in _process (linhas 13196 a 13201). Códigos 
mais altos não são passados para in_process, mas uma 
verificação é feita para os códigos de ALT-Seta para a es¬ 
querda, ALT-Seta para a direita ou AIT-F1 a ALT-F12, e se 
um desses é encontrado, select_console é chamada para 
alternar entre consoles virtuais. 

Makejbreak (linha 13222) converte códigos de varre¬ 
dura para ASCII e, então, atualiza as variáveis que monito¬ 
ram as teclas modificadoras. Primeiro, contudo, ela faz uma 
verificação quanto à mágica combinação CTRL-ALT-DEL 
que usuários de PC conhecem bem como a maneira para 
forçar uma reinicialização sob o MS-DOS. Um desligamen¬ 
to correto é desejável, porém, então antes de tentar iniciar 
as rotinas da BIOS do PC, um sinal SIGABRT é enviado para 
init, o processo-pai de todos os outros processos. Init é en¬ 
carregado de capturar esse sinal e de interpretá-lo como 
um comando para começar um processo de desligamento 
correto, antes de causar um retorno para o monitor de ini¬ 
cialização, a partir do qual uma reinicialização completa 
do sistema ou uma reinicialização do MI.MX poder ser co¬ 
mandada. Naturalmente, não é aceitável esperar esse tra¬ 
balho todas as vezes. A maioria dos usuários entende os 
perigos de um desligamento brusco e não pressiona CTRL- 
ALT-DEL até que algo realmente dê errado, e o controle nor- 
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Figura 3-46 Códigos de escape gerados pelo teclado numérico. Enquanto os códigos de varredura para teclas comuns são traduzidos 
em códigos ASCII, códigos ''pseudo-ASCII", com valores maiores do que OxFF, são atribuídos às teclas especiais. 
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mal do sistema tornou-se impossível. Nesse ponto, é possí¬ 
vel que o sistema esteja tão corrompido que o envio orde¬ 
nado de um sinal para outro processo pode ser impossível. 
Essa é a razão por que há uma variável estática CAD_çount 
em makejjreak. A maioria das quedas de sistema deixa o 
sistema de interrupções ainda em funcionamento, de modo 
que a entrada de teclado ainda pode ser recebida, e a tarefa 
de relógio pode manter a tarefa de terminal em execução. 
Aqui o MiNix tira proveito do comportamento esperado dos 
usuários de computador, que tendem a pressionar teclas 
repetidamente quando algo não parece funcionar correta¬ 
mente. Se a tentativa de enviar SIGABRT para init falhar, e 
o usuário pressionar CTRL-ALT-DEL duas vezes mais, uma 
chamada para wreboot é feita diretamente, causando um 
retorno para o monitor sem passar pela chamada a init. 

A parte principal de makejjreak não é difícil de acom¬ 
panhar. A variável make registra se o código de varredura 
foi gerado pelo pressionamento ou pela liberação de uma 
tecla e, então, a chamada para map_key retorna o código 
ASCII para ch. Em seguida, vem um switch em ch (linhas 
13248 13294). Consideraremos dois casos: uma tecla co¬ 
mum e uma tecla especial. Para uma tecla comum, ne¬ 
nhum dos casos coincide, e nada deve acontecer no caso- 
padrão também (linha 13292 ), uma vez que os códigos 
normais de teclas são aceitos somente na fase de pressio¬ 
namento da tecla. Se, de qualquer maneira, um código de 
tecla comum é aceito na liberação da tecla, um valor de -1 
é colocado no lugar aqui e isso é ignorado pelo chamador, 
kb_read. Uma tecla especial, por exemplo CTRL, é identi¬ 
ficada no lugar apropriado no switch, neste caso na linha 
13249. A variável correspondente, neste caso control, re¬ 
gistra 0 estado de make, e -1 é substituído pelo código de 
caractere a ser retornado (e ignorado). 0 tratamento das 
teclas ALT, CALOCK, NLOCK e SLOCK é mais complicado, 
mas para todas essas teclas especiais 0 efeito é semelhante: 
uma variável registra 0 estado atual (para teclas que são 
somente efetivas enquanto pressionadas) ou alterna 0 es¬ 
tado anterior (para as teclas de bloqueio). 

Há mais um caso a considerar, 0 do código EXTKEY e a 
variável esc. Isso não deve ser confundido com a tecla ESC 
no teclado, que retorna 0 código ASCII OxlB. Não há como 
gerar 0 código EXTKEY somente pressionando qualquer te¬ 
cla ou uma combinação de teclas; ele é 0 prefixo de tecla 
estendida do teclado do PC, 0 primeiro byte de um código 
de varredura de 2 bytes que significa que uma tecla que 
não era parte do complemento de teclas do PC original mas 
que tem 0 mesmo código de varredura, foi pressionada. Em 
muitos casos, 0 software trata as duas teclas identicamen¬ 
te. Por exemplo, esse é quase sempre 0 caso para a tecla “/ 
” normal e a tecla “/” no teclado de numérico. Em outros 
casos, pode-se querer distinguir essas teclas. Muitos dos 
leiautes de teclado, por exemplo, para outros idiomas que 
não 0 inglês tratam as teclas ALT esquerda e direita dife¬ 
rentemente, para suportar teclas que devem gerar três có¬ 
digos diferentes de caractere. As duas teclas ALT geram 0 
mesmo código de varredura (56), mas 0 código EXTKEY 
precede esse quando 0 ALT da direita é pressionado. Quan¬ 


do 0 código EXTKEYé retornado, 0 sinalizador esc é ligado. 
Nesse caso, makejjreak retorna a partir de dentro do 
switch, pulando assim 0 último passo antes de um retorno 
normal, que configura esc como zero em qualquer outro 
caso (linha 13295). Isso tem 0 efeito de fazer 0 esc efetivo 
somente para 0 código mais próximo recebido. Se você co¬ 
nhece as complexidades do teclado de PC como comumente 
é utilizado, isso lhe será tanto familiar quanto um pouco 
estranho, porque a BIOS do PC não permite ler 0 código de 
varredura para uma tecla ALT e retornar um valor diferen¬ 
te para 0 código estendido como faz 0 MINIX. 

Setjeds (linha 13303) liga e desliga as luzes que indi¬ 
cam se as teclas Num Lock, Caps Lock ou Scroll Lock em 
um teclado de PC estão pressionadas. Um byte de controle, 
LEDjCODE. é gravado em uma porta de saída instruindo 
0 teclado que 0 próximo byte gravado nessa porta é para 
controle das luzes, e 0 status das três luzes é codificado em 
3 bits desse próximo byte. As próximas duas funções supor¬ 
tam essa operação. Kb_wait (linha 13327) é chamada para 
determinar se 0 teclado está pronto para obter uma seqüên- 
cia de comando, e kb_ack (linha 13343) é chamada para 
verificar se 0 comando foi reconhecido. Esses dois coman¬ 
dos utilizam espera ativa, lendo continuamente até que um 
código desejado seja visto. Isso não é uma técnica reco¬ 
mendada para tratar a maioria das operações de E/S, mas 
ligar e desligar luzes do teclado não será feito com muita 
freqüência e fazer isso de maneira ineficiente não desper¬ 
diça muito tempo. Note também que ambos, kbjjuait e 
kb_ack, poderiam falhar e é possível verificar pelo código 
de retorno se isso acontecer. Mas ligar a luz no teclado não 
é suficientemente importante para merecer uma verifica¬ 
ção do valor retornado por qualquer chamada, e setjeds 
apenas prossegue cegamente. 

Como 0 teclado é parte do console, sua rotina de inici¬ 
alização kbjnit (linha 13359) é chamada a partir de 
scrjnit em console, c, não diretamente de ttyjnit em tty. c. 
Se consoles virtuais estiverem ativados, (i. e., NRjCONS 
em include/minix/config.h é maior que 1), kbjnit será 
chamada uma vez para cada console lógico. Depois da pri¬ 
meira vez, a única parte de kbjnit que é essencial para 
consoles adicionais está configurando em atribuir 0 ende¬ 
reço áekb_readp?ixztp->tty_devread (linha 13367), mas 
nenhum prejuízo é causado por repetir 0 resto da função. 
O resto de kbjnit inicializa algumas variáveis, configura 
as luzes no teclado e varre 0 teclado para certificar-se de 
que nenhuma tecla pressionada restante seja lida. Quando 
tudo está pronto, ela áwva.putjrqj:andler e enablejrq-, 
então, kbdjiwjnt será executada sempre que uma tecla 
for pressionada ou liberada. 

As próximas três funções são todas bastante simples. 
Kbdjoadmap (linha 13392) é quase trivial. Ela échama¬ 
da por dojoctl em tty.c para fazer a operação de cópia de 
um mapa de teclado do espaço do usuário para sobrescre- 
ver 0 mapa de teclado padrão compilado pela inclusão de 
um arquivo fonte de mapa de teclado no início d ekeymap.c. 

Funcjiey (linha 13405) é chamada a partir de 
kb_read para ver se uma tecla especial destinada a proces- 
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sarnento local foi pressionada. A Figura 3-47 resume essas 
teclas e seus efeitos. 0 código chamado está localizado em 
vários arquivos. Os códigos F1 e F2 ativam o código em 
dmp.c, que discutiremos na próxima seção. O código F3 
ativa toggle_scroll, que está em console, c, que também será 
discutido na próxima seção. As chamadas CF7, CF8 e CF9 
causam chamadas a sigchar, em tty.c. Quando recursos de 
rede são adicionados ao mintx, um case adicional, para 
captar o código F5, é adicionado para exibir estatísticas de 
Ethernet. Há também um grande número de outros códi¬ 
gos de varredura que poderiam ser utilizados para ativar 
outras mensagens de depuração ou eventos especiais do 
console. 

Scan _keyboard (linha 13432) trabalha no nível de 
interface de hardware, lendo e gravando bytes em portas de 
E/S. A controladora de teclado é informada de que um ca¬ 
ractere foi lido pela seqüência nas linhas 13440 a 13442, a 
qual lê um byte, grava-o novamente com o bit mais signi¬ 
ficativo configurado como 1 e, então, regrava-o com o 
mesmo bit como 0. Isso impede que os mesmos dados este¬ 
jam em uma leitura subseqüente. Não há nenhuma verifi¬ 
cação de status na leitura do teclado, mas não deve haver 
nenhum problema de qualquer maneira, uma vez que 
scan _keyboard somente é chamada em resposta a uma 
interrupção, com a exceção da chamada a partir de kbjnit 
para limpar qualquer lixo. 

A última função em keyboard.c é wreboot (linha 
13450). Se invocada como um resultado de uma pane de 
sistema, oferece uma oportunidade para o usuário utilizar 
as teclas de função para exibir as informações de depura¬ 
ção. O laço nas linhas 13478 a 13487 é outro exemplo de 
espera ativa. O teclado é lido repetidamente até que um 
ESC seja digitado. Com certeza, alguém poderia sustentar 
que uma técnica mais eficiente é necessária depois de uma 
queda, enquanto se espera um comando para reiniciali¬ 
zar. Dentro do hqo,func_ke)' é chamada para oferecer uma 
possibilidade de obter as informações que talvez ajudem a 
analisar a causa de uma queda. Não discutiremos mais 
detalhes do retorno para o monitor. Os detalhes são muito 
específicos de hardware e não têm muita relação com o 
sistema operacional. 


3.9-6 Implementação do Driver 
de Vídeo 

O vídeo do IBM PC pode ser configurado como vários 
terminais virtuais, se memória suficiente estiver disponí¬ 
vel. Examinaremos o código dependente de dispositivo do 
console nesta seção. Também veremos as rotinas de dump 
para depuração que utilizam serviços de baixo nível do te¬ 
clado e do vídeo. Esses oferecem suporte para interação li¬ 
mitada com o usuário no console, quando outras partes 
normais do sistema mintx não estão funcionando e podem 
oferecer informações úteis para monitorar o sistema mes¬ 
mo próximo de uma falha total. 

Suporte específico de hardware para saída de console e 
vídeo mapeados em memória do PC está em console.c. A 
estrutura console é definida nas linhas 13677 a 13693- Em 
um sentido, essa estrutura é uma extensão da estrutura tty 
definida em tty. c. Na inicialização, o campo tp—>tty_priv 
da estrutura tty de um console recebe um ponteiro para a 
sua própria estrutura console. O primeiro item na estrutu¬ 
ra console é um ponteiro de volta para a estrutura tty cor¬ 
respondente. Os componentes de uma estrutura console são 
o que se esperaria para um monitor de vídeo: variáveis para 
registrar a linha e a coluna da posição do cursor, os ende¬ 
reços de início e o limite da memória utilizada para exibi¬ 
ção, o endereço de memória apontado pelo ponteiro de base 
do chip da controladora e o endereço atual do cursor. Ou¬ 
tras variáveis são utilizadas para gerenciar seqüências de 
escape. Como os caracteres são inicialmente recebidos como 
bytes de 8 bits e devem ser combinados com bytes de atri¬ 
buto e transferidos como palavras de 16 bits para memória 
de vídeo, um bloco a ser transferido é criado em 
c_ramqueue, uma matriz suficientemente grande para 
armazenar uma linha de 80 colunas inteira de pares atri¬ 
buto-caractere de 16 bits. Cada console virtual precisa de 
uma estrutura console, e o espaço de armazenamento é 
alocado na matriz consjable (linha 13696 ). Como fize¬ 
mos com as estruturas ttyekb_s, normalmente iremos re¬ 
ferenciar os elementos de uma estrutura console, utilizan¬ 
do um ponteiro, por exemplo, cons—>c_tty. 


Tecla 

Propósito 

F1 

Exibe a tabela de processos 

F2 

Exibe os detalhes de utilização de memória pelo processo 

F3 

Alterna entre rolagem por hardware e por software 

F5 

Mostra estatísticas de Ethernet (se 0 suporte de rede for compilado) 

CF7 

Envia SIGQUIT, mesmo efeito que CTRLA 

CF8 

Envia SIGIN_, mesmo efeito que DEL 

CF9 

Envia SIGKILL, mesmo efeito que CTRL-U 


Figura 3-47 As teclas de função detectadas \>orfu?ic_key(). 
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A função cujo endereço é armazenado em cada entra¬ 
da tp->tty_devurite do console é consjvrite (linha 
13729). Ela é chamada de apenas um lugar bandle_events 
em tty.c. A maioria das outras funções em console.c existe 
para suportar essa função. Quando ela é chamada pela pri¬ 
meira vez depois de um processo de cliente fazer uma cha¬ 
mada WRITE, os dados a sofrerem saída estão no buffer do 
cliente, 0 qual pode ser localizado, utilizando os campos 
tp->tty_outproc e tp—>out_vir na estrutura tty. Os cam¬ 
pos tp->tty_outleft informam quantos caracteres estão 
para ser transferidos, e 0 campo tp—>tty jutcum é inici¬ 
almente zero, indicando que nenhum ainda foi transferi¬ 
do. Essa é a situação normal ao entrar em consjurite, por¬ 
que, normalmente, uma vez chamada, ela transfere todos 
os dados requeridos na chamada original. Entretanto, se 0 
usuário quiser reduzir a velocidade desse processo para re¬ 
visar os dados na tela, ele pode entrar um caractere STOP 
(CTRL-S) no teclado, 0 que resulta na ativação do sinali¬ 
zador tp->tty Jnhibited. Cons_write retorna imediata¬ 
mente quando esse sinalizador está ativado, mesmo que 0 
WRITE não seja completado. Nesse caso, handle_evmts con¬ 
tinuará a chamar consjrite e, quando tp~>tty_ inhibi- 
ted for finalmente redefinido pelo usuário ao digitar um 
caractere START (CTRL-Q), cons_write continua com a 
transferência interrompida. 

0 único argumento de consjurite é um ponteiro para 
a estrutura tty do console particular, assim a primeira coi¬ 
sa que deve ser feita é iniciar cons , 0 ponteiro para a estru¬ 
tura console desse console (linha 13741). Portanto, como 
handle_events chama consjurite sempre que executa, a 
primeira ação é um teste para ver se realmente há trabalho 
a ser feito. Caso contrário, é feito um retorno rápido (linha 
13746). Seguindo-se a isso, 0 laço principal nas linhas 
13751 a 13778 é iniciado. Esse laço é muito semelhante 
em estrutura ao laço principal de injransfer em tty.c. Um 
buffer local que pode armazenar 64 caracteres é preenchi¬ 
do chamando physjopy para obter os dados do buffer do 
cliente, 0 ponteiro para a origem e a contagem são atuali¬ 
zados, e, então, cada caractere no buffer local é transferido 
para a matriz cons->c_ramqueue, junto com um byte de 
atributo, para posterior transferência à tela por flush. Há 
mais de uma maneira de fazer essa transferência, como 
vimos na Figura 3-39. Outjhar poder ser chamada para 
fazer isso para cada caractere, mas é previsível que nenhum 
dos serviços especiais de outjshar seja necessário se 0 ca¬ 
ractere for um caractere visível uma seqüência de escape 
não está em progresso, a largura da tela não foi excedida e 
cons—>c_ramqueue não está cheia. Se 0 serviço comple¬ 
to de outjshar não for necessário, 0 caractere é colocado 
diretamente em cons—>c_ramqueue, junto com 0 byte de 
atributo (recuperadode cons—xsjttr ), e cons—>c_ru'ords 
(0 índice na fila), cons—>c_column (que armazena a co¬ 
luna na tela), e tbuf, 0 ponteiro no buffer, são incrementa¬ 
dos. Essa colocação direta de caracteres em cons- 
>cjamqueue corresponde à linha tracejada no lado es¬ 
querdo da Figura 3-39- Se necessário, outjshar é chama¬ 
da (linhas 13766 a 13777). Ela faz toda a contabilidade e 


adicionalmente chama flush, a qual faz a transferência 
final para memória da tela, quando necessário. A transfe¬ 
rência do buffer do usuário para 0 buffer local e para a fila 
é repetida, contanto que tp->tty. jutleft indique que ain¬ 
da há caracteres a serem transferidos, e 0 sinalizador tp- 
>tty jnhibited não tenha sido ativado. Quando a transfe¬ 
rência pára, seja porque a operação write esteja completa, 
seja porque tp->tty Jnhibited foi ativado, flush é chama¬ 
da novamente para transferir os últimos caracteres na fila 
para memória da tela. Se a operação estiver completa (tes¬ 
tado vendo se tp->tty jutleft é zero), uma mensagem de 
resposta é enviada, chamando tty_ reply (linhas 13784 e 
13785). 

Além das chamadas a consjvrite a partir de handle_ 
events, os caracteres a serem exibidos são também envia¬ 
dos para os consoles por echo e rawecho na parte indepen¬ 
dente de hardware da tarefa de terminal. Se 0 console é 0 
dispositivo atual de saída, chamadas via 0 ponteiro tp- 
>tty_echo são dirigidas para a próxima função, consjcho 
(linha 13794). Consjcho faz todo seu trabalho, chaman¬ 
do outjhar e, então , flush. À entrada do teclado chega 
caractere por caractere, e a pessoa que faz a digitação quer 
ver 0 eco sem nenhum atraso perceptível, portanto, colo¬ 
car os caracteres na fila de saída seria insatisfatório. 

Agora chegamos a outjhar (linha 13809). Ela faz um 
teste para ver se uma seqüência de escape está em progres¬ 
so, chamando parsejscape e, então, retornando imedia¬ 
tamente se estiver (linhas 13814 a 13816). Caso contrário, 
um switch é iniciado para verificar casos especiais: nulo, 
backspace, caractere de sinal sonoro e assim por diante. 0 
tratamento da maioria desses é fácil de acompanhar. A que¬ 
bra de linha e a tabulação são os mais complicados, uma 
vez que envolvem alterações complicadas na posição do 
cursor na tela e podem exigir rolagem também. O último 
teste é para 0 código ESC. Se for localizado, 0 sinalizador 
cons->cjsc_state é ativado (linha 13871) e chamadas 
futuras -àoutjhar são dirigidas para parsejscape até que 
a seqüência esteja completa. No fim, 0 padrão é assumido 
para caracteres imprimíveis. Se a largura da tela for exce¬ 
dida, a tela pode necessitar ser rolada, e flush é chamada. 
Antes de um caractere ser colocado na fila de saída um 
teste é feito para ver se a fila não está cheia, e flush é cha¬ 
mada se estiver. Colocar um caractere na fila requer a mes¬ 
ma contabilidade que já vimos em consjrite. 

A próxima função é scrolljcreen (linha 13896). 
Scrolljcreen manipula tanto a rolagem para cima, a si¬ 
tuação normal que deve ser tratada sempre que a linha 
inferior na tela estiver cheia, e a rolagem para baixo, que 
ocorre quando comandos de posicionamento do cursor ten¬ 
tarem mover 0 cursor além da linha superior da tela. Para 
cada direção de rolagem, há três possíveis métodos. Esses 
são requeridos para suportar diferentes tipos de placas de 
vídeo. 

Veremos 0 caso da rolagem para cima. Para começar, 0 
tamanho da tela menos uma linha é atribuído a chars. A 
rolagem por software é realizada por um única chamada a 
vidjídjopy para mover chars caracteres mais para bai- 
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xo na memória, sendo que o tamanho do movimento é o 
número de caracteres em uma linha. Vid_vid_copy pode 
fazer referência circular à memória, isto é, se solicitada a 
mover um bloco de memória que ultrapassa a extremida¬ 
de superior do bloco atribuído ao monitor de vídeo, ela 
busca a porção de memória que ultrapassa este limite (fe- 
tctí) a parte de estouro a partir da extremidade inferior do 
bloco de memória e move-o para um endereço mais alto 
que a parte que é movida para baixo, tratando o bloco in¬ 
teiro como uma matriz circular. A simplicidade da chama¬ 
da esconde uma operação claramente lenta. Mesmo que 
vid_vid_copy seja uma rotina de linguagem assembly 
definida em klib386.s, essa chamada requer que a CPU 
mova 3840 bytes, o que é um trabalho grande mesmo para 
a linguagem assembly. 

O método de rolagem por software nunca é o padrão; o 
operador deve selecioná-lo somente se a rolagem por har¬ 
dware não funcionar ou não for desejada por alguma ra¬ 
zão. A razão disso talvez seja o desejo de utilizar o coman¬ 
do screendump para salvar a memória de tela em um ar¬ 
quivo. Quando a rolagem por hardware está em efeito, é 
provável que screendump gere resultados inesperados, por¬ 
que é provável que o início da memória de tela não coinci¬ 
da com o início da tela visível. 

Na linha 13917, a variável wrap é testada como a pri¬ 
meira parte de um teste composto. Wrap é verdadeira para 
adaptadoras de vídeo mais antigas que podem suportar ro¬ 
lagem por hardware, e se o teste falhar, a rolagem por har¬ 
dware simples ocorre na linha 13921, onde o ponteiro da 
origem utilizado pelo chip da controladora de vídeo, cons- 
>c_org, é atualizado para apontar para o primeiro carac¬ 
tere a ser exibido no canto superior esquerdo do vídeo. Se 
wrap for FALSE, o teste composto continua com um teste 
para ver se o bloco a ser movido para cima na operação de 
rolagem ultrapassa os limites do bloco de memória atribu¬ 
ído para esse console. Se isso acontecer, vid_vid_copy é 
chamada novamente para fazer a movimentação circular 
do bloco para o início da memória alocada do console, e o 
ponteiro que indica a origem é atualizado. Se não houver 
sobreposição, o controle passa para o método simples de 
rolagem por hardware sempre utilizado por controladoras 
de vídeo mais antigas. Isso consiste em ajustar cons— 
>c_org e, então, colocar a nova origem no registrador cor¬ 
reto do chip da controladora. A chamada que realiza isso é 
feita mais tarde, sendo que é uma chamada para limpar a 
linha inferior da tela. 

O código de rolagem para baixo é muito semelhante ao 
de rolagem para cima. Por fim, mem_vid_copy é chama¬ 
da para limpar a linha inferior (ou superior) endereçada 
por newjine. Então, set_6845 é chamada para gravar a 
nova origem de cons->c_org nos registradores apropria¬ 
dos, e flush certifica-se de que todas as alterações toma¬ 
ram-se visíveis na tela. 

Mencionamos flush (linha 13951) várias vezes. Ela 
transfere os caracteres na fila para a memória de vídeo utili¬ 
zando mem_vid_copy, atualiza algumas variáveis e, en¬ 
tão, assegura-se de que os números de linha e de coluna 


são razoáveis, ajustando-os se, por exemplo, uma seqüên- 
cia de escape tentou mover o cursor para uma posição de 
coluna negativa. Por fim, um cálculo de onde o cursor de¬ 
veria estar é feito e é comparado com cons->c_cur Se 
eles não coincidirem e se a memória de vídeo que atual¬ 
mente está sendo tratada pertence ao console virtual atual, 
uma chamada zset_6845 é feita para configurar o valor 
correto no registrador de cursor da controladora. 

A Figura 3-48 mostra como o tratamento de seqüências 
de escape pode ser representado como uma máquina de 
estados finitos. Isso é implementado por parse_escape (li¬ 
nha 13986) que é chamada no início de out_char se cons- 
>c_esc_state não for zero. Um ESC em si é detectado por 
out_char e torna cons—>c_esc_state igual a 1. Quando o 
próximo caractere é recebido, parse_escape prepara para 
processamento adicional colocando um ’\0’ em cons- 
>c_esc_intro, um ponteiro para o início da matriz de pa¬ 
râmetros, cons->c_esc_parmv\f)\ em cons—>c_ 
esc_J>armv e zeros na própria matriz de parâmetros. En¬ 
tão, o primeiro caractere que se segue a ESC é examinado 
— valores válidos são “[” ou “M”. No primeiro caso, o 
“ [” é copiado para cons—>c_esc_intro, e o estado é avan¬ 
çado para 2. No segundo caso, do_escape é chamada para 
executar a ação, e o estado de escape é redefinido para zero. 
Se o primeiro caractere depois do ESC não for válido, ele é 
ignorado, e os caracteres seguintes são exibidos normal¬ 
mente. 

Quando é encontrada uma seqüência ESC [o próximo 
caractere entrado é processado pelo código do estado de 
escape 2. Há três possibilidades nesse ponto. Se o caractere 
for numérico, seu valor é extraído e adicionado a 10 vezes 
o valor existente na posição atualmente apontada por cons- 
>c_esc_parmp, inicialmente cons—>c_esc__parmv[0] 
(que foi inicializado com zero). O estado de escape não 
muda. Isso torna possível entrar uma série de algarismos 
decimais e acumular um parâmetro numérico grande, 
embora o valor máximo atualmente reconhecido pelo MI- 
NIX seja 80, utilizado pela seqüência que move o cursor 
para uma posição arbitrária (linhas 14027 a 14029). Se o 
caractere é um ponto-e-vírgula, o ponteiro para a string de 
parâmetros é avançado, de modo que valores numéricos 
sucessivos podem ser acumulados no segundo parâmetro 
(linhas 14031 a 14033). Se fosse necessário modificar 
MAX_ESC_PARMS para alocar uma matriz maior para os 
parâmetros, esse código não teria de ser alterado para acu¬ 
mular valores numéricos adicionais depois da entrada dos 
parâmetros adicionais. Por fim, se o caractere não é um 
algarismo numérico nem um ponto-e-vírgula, do_escape 
é chamada. 

Do_escape (linha 14045) é uma das mais longas fun¬ 
ções no código-fonte de sistema do MINIX, embora o com¬ 
plemento do MINIX para seqüências de escape reconheci¬ 
das seja relativamente modesto. Em toda sua extensão, 
porém, o código deve ser fácil de acompanhar. Depois de 
uma chamada inicial, a flush para certificar-se de que o 
monitor de vídeo está inteiramente atualizado, há uma 
escolha simples, dependendo se o caractere imediatamen- 
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parâmetros 

numéricos 


do„escape 

Figura 3-48 Máquina de estados finitos para processamento de seqüências de escape. 


te seguinte ao caractere ESC era um introdutor de uma 
seqüência especial de controle ou não. Se não, há somente 
uma ação válida, mover o cursor uma linha se a seqüência 
era ESC M. Note que o teste para o “M" é feito dentro de um 
switch com uma ação-padrão, como uma verificação de 
validade e em antecipação à adição de outras seqüências 
que não utilizam o formato ESC [. A ação é típica de mui¬ 
tas seqüências de escape: a variável cons—>c_row é inspe¬ 
cionada para determinar se é necessária rolagem. Se o cur¬ 
sor já estiver na linha 0, uma chamada SCR0LL_D0WNé 
feita para scroll_screen \ caso contrário, o cursor é movido 
para cima uma linha. Este último é realizado simplesmente 
decrementando cons->c_row e, então, chamando flush. 
Se um introdutor de seqüência de controle for localizado, 
o código seguinte a else na linha 14069 é assumido. Um 
teste é feito quanto a “[", o único introdutor de seqüência 
de controle atualmente reconhecido pelo MINIX. Se a se¬ 
qüência for válida, o primeiro parâmetro localizado na se¬ 
qüência de escape, ou zero se nenhum parâmetro tiver sido 
entrado, será atribuído a value (linha 14072). Se a seqüên¬ 
cia for nula, nada acontecerá exceto que o grande switch 
que se segue (linhas 14073 a 14272) é pulado, e o estado 
de escape é redefinido para zero antes de retornar de 
do_escape. No caso mais interessante em que a seqüência 
é válida, o switch é entrado. Não discutiremos todos os ca¬ 
sos: apenas observaremos alguns casos distintos que são 
bastante representativos dos tipos de ação governados por 
seqüências de escape. 

As primeiras cinco seqüências são geradas, sem nenhum 
argumento numérico, pelas quatro teclas de “seta” e a te¬ 
cla Home no teclado IBM PC. As duas primeiras, ESC [A e 
ESC [B, são semelhantes a ESC M, exceto que podem acei¬ 
tar um parâmetro numérico e mover para cima e para bai¬ 
xo por mais de uma linha e não rolam a tela se o parâme¬ 
tro especifica um movimento que excede os limites da tela. 
Nesses casos, flush pega solicitações para mover fora dos 
limites e limita o movimento à última ou à primeira li¬ 


nha, conforme apropriado. As próximas duas seqüências, 
ESC [C e ESC [D, que movem o cursor para a direita e para 
a esquerda, são de maneira semelhante limitados por flush. 
Quando geradas pelas teclas de “seta” não há nenhum ar¬ 
gumento numérico e, assim, o movimento-padrão de uma 
linha ou de uma coluna ocorre. 

A próxima seqüência, ESC [H, pode ter dois parâmetros 
numéricos, ESC [20;60H, por exemplo. Os parâmetros es¬ 
pecificam uma posição absoluta em vez da posição relati¬ 
va atual e são convertidos de números baseados em 1 a 
números baseados em 0 para interpretação adequada. A 
tecla Home gera a seqüência-padrão (nenhum parâme¬ 
tro) que move o cursor para a posição (1, 1). 

As próximas duas seqüências, ESC [xj e ESC [xK, lim¬ 
pam parte da tela inteira ou da linha atual, dependendo do 
parâmetro que é dado. Em cada caso, uma contagem de 
caracteres é calculada. Por exemplo, para ESC [1J, count 
recebe o número de caracteres do início da tela até a posi¬ 
ção do cursor: e a contagem de um parâmetro de posição, 
dst. que pode ser o início da tela, cons->c_org, ou a posi¬ 
ção atual do cursor, cons >c_cur, são utilizados como pa¬ 
râmetros para uma chamada a mem_vid_copy. Esse pro¬ 
cedimento é chamado com um parâmetro que causa o pre¬ 
enchimento da região especificada com a cor de fundo atu¬ 
al. 

As próximas quatro seqüências inserem e excluem li¬ 
nhas e espaços na posição do cursor, e suas ações não re¬ 
querem explicação detalhada. O último caso, ESC [w,m 
(note que o n representa um parâmetro numérico, mas o 
“m” é um caractere literal) tem seu efeito sobre cons - 
>c_attr, o byte de atributo que é intercalado entre os códi¬ 
gos de caractere quando são gravados na memória de ví¬ 
deo. 

A próxima função, set_684 5 (linha 14280), é utilizada 
sempre que necessário para atualizar o chip da controla¬ 
dora de vídeo. O 6845 tem registradores de 16 bits internos 
que são programados 8 bits por vez. Gravar um único re- 
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gistrador requer quatro operações de gravação em porta de 
E/S. As chamadas lock e urtlock são utilizadas para desati¬ 
var as interrupções, que podem causar problemas se tive¬ 
rem permissão para interromper a seqüência. Alguns re¬ 
gistradores do chip controlador de vídeo 6845 são mostra¬ 
dos na Figura 3-49- 

A função beep (linha 14300) é chamada quando um 
caractere CTRL-G deve sofrer saída. Ela tira proveito do 
suporte interno fornecido pelo PC para fazer sons envian¬ 
do uma onda quadrada para o alto-falante. 0 som é inici¬ 
ado pelo tipo de manipulação mágica de portas de E/S que 
apenas programadores de linguagem assembly podem gos¬ 
tar, e novamente com alguma preocupação com o fato de 
que uma parte crítica do processo deve ser protegida con¬ 
tra interrupções. A parte mais interessante do código é a 
utilização da capacidade da tarefa de relógio de configurar 
um alarme, que pode ser utilizado para iniciar uma fun¬ 
ção. A próxima rotina, stop _beep (linha 14329), é a rotina 
cujo endereço é colocado na mensagem para a tarefa de 
relógio. Ela pára o som depois de o tempo determinado ter 
passado e também redefine o sinalizador beeping que é 
utilizado para impedir que chamadas supérfluas à rotina 
beep tenham qualquer efeito. 

Scr_mit (linha 14343) é chamada/V7?_C’OAb’vezes por 
tty_init. A cada vez, seu argumento é um ponteiro para 
uma estrutura tty, um elemento da ttyjable. Nas linhas 
14354 e 14355, Une, a ser utilizado como índice na matriz 
cons_table, é calculado, é testado quanto à validade, e, se 
válido, utilizado para iniciar cons, o ponteiro para a entra¬ 
da atual da tabela de console. Nesse ponto, o campo cons— 
>c_tty pode ser inicializado com o ponteiro para a estru¬ 
tura tty principal do dispositivo e tp->tty_priv, por sua 
vez, poder ser apontado para a estrutura console_t desse 
dispositivo. Em seguida, kb_init é chamada para iniciali- 
zar o teclado, e, então, os ponteiros para rotinas específicas 
de dispositivo são configurados, tp->tty_devurite aponta 
para cons_write e tp—>tty_echo aponta para cons_echo. 
0 endereço de E/S do registrador de base da controladora 
CRT é buscado e o endereço e o tamanho da memória de 
vídeo são determinados nas linhas 14368 a 14378, e o si¬ 
nalizador wrap (utilizado para determinar como rolar) é 
configurado de acordo com a classe da controladora de ví¬ 
deo em uso. Nas linhas 14382 a 14384, o descritor de seg¬ 
mento para a memória de vídeo é inicializado na tabela 
global de descritores. 

Em seguida, vem a inicialização dos consoles virtuais. 
Cada vez que scrjnit é chamada, o argumento é um valor 


diferente de tp, e, portanto, um Une e um cons diferentes 
são utilizados nas linhas 14393 a 14396 para oferecer a 
cada console virtual sua própria parte da memória de ví¬ 
deo. Cada tela é, então, limpa, pronta para iniciar e, por 
fim, o console 0 é selecionado para ser o primeiro ativo. 

As rotinas restantes em console.c são curtas e simples e 
iremos revisá-las rapidament e.Putk (linha 14408) foi men¬ 
cionada anteriormente. Ela imprime um caractere em 
nome de qualquer código vinculado na imagem do kemel 
que precisa do serviço, sem passar pelo sistema de arqui¬ 
vos. Toggle_scroll (linha 14429) faz o que seu nome diz; 
ela comuta o sinalizador que determina se é utilizada ro¬ 
lagem por hardware ou por software. Ela também exibe 
uma mensagem na posição atual do cursor para identifi¬ 
car o modo selecionado. Cons_stop (linha 14442) reinici¬ 
aliza o console para o estado que o monitor de boot espera, 
antes de um desligamento ou de uma reinicialização. 
ConsjorgO (linha 14456) é utilizado apenas quando uma 
mudança no modo de rolagem é forçado pela tecla F3 ou 
ao preparar o desligamento. Select_console (linha 14482) 
seleciona um console virtual. Ela é chamada com o novo 
índice e chama set_6845 duas vezes para fazer a controla¬ 
dora de vídeo exibir a parte adequada da memória de vídeo. 

As últimas duas rotinas são altamente específicas de 
hardware. Conjcadfont (linha 14497) carrega uma fonte 
em um adaptador gráfico, em suporte da operação IOCTL 
TIOCSFON. Ela chama ga _program (linha 14540) para 
fazer uma série de gravações mágicas em uma porta de 
E/S que faz com que a memória de fonte do adaptador de 
vídeo, que normalmente não é endereçável pela CPU, seja 
visível. Então ,physjcopy é chamada para copiar os dados 
da fonte para essa área da memória, e outra seqüência 
mágica é invocada para retornar o adaptador gráfico ao 
seu modo normal de operação. 

Dumps de Depuração 

O grupo final de procedimentos que discutiremos na 
tarefa de terminal foi originalmente projetado somente para 
utilização temporária em uma depuração do mintx. Eles 
podem ser removidos quando esse auxílio não for mais 
necessário, mas muitos usuários irão achá-los úteis e vão 
deixá-los onde estão. Eles são particularmente úteis para 
modificar-se o MiNix. 

Como vimos ,func_keyé chamada no início de kb_read 
para detectar códigos de varredura utilizados para controle 
e depuração. As rotinas de dump chamadas quando as te- 


Registradores 

Função 

10-11 

Tamanho do cursor 

12-13 

Endereço inicial para desenhar a tela 

14-15 

Posição do cursor 


Figura 3-49 Alguns registradores do 6845. 



202 TANENBAUM & WOODHULL 


cias F1 e F2 são captadas estão em dmp.c. A primeira, 
p_dmp , (linha 14613) exibe informações básicas de pro¬ 
cesso de todos os processos, incluindo algumas informa¬ 
ções sobre utilização da memória, quando a tecla F1 é pres¬ 
sionada. A segunda, map_dmp (linha 14660), oferece in¬ 
formações mais detalhadas sobre a utilização de memória 
em resposta a F2. Proc_name (linha 14690) suporta 
p_dmp, procurando nomes de processo. 

Como esse código está completamente contido dentro 
do próprio binário do kernel e não executa como um pro¬ 
cesso ou como uma tarefa de usuário, ele com freqüência 
continua a funcionar corretamente, mesmo depois de uma 
grande falha do sistema. Naturalmente, essas rotinas são 
acessíveis somente no console. As informações fornecidas 
pelas rotinas de dump não podem ser redirecionadas para 
um arquivo nem para qualquer outro dispositivo, assim 
não são opções a impressão ou a utilização por uma cone¬ 
xão de rede. 

Sugerimos que o primeiro passo ao tentar adicionar 
qualquer melhoria ao MiNix seja estender as rotinas de 
dump para que ofereçam maiores informações sobre o as¬ 
pecto do sistema que você deseja melhorar. 

3.10 A TAREFA DE SISTEMA NO MINIX 

Uma conseqüência de fazer os processos de servidor do 
sistema de arquivos e do gerenciador de memória fora do 
kertiel é que ocasionalmente eles têm algumas informa¬ 
ções que o kernel precisa. Essa estrutura, entretanto, proí- 
be-os de simplesmente gravá-las em uma tabela do kernel. 
Por exemplo, a chamada de sistema fork é tratada pelo 
gerenciador de memória. Quando um novo processo é cri¬ 
ado, o kernel deve saber sobre ele, para agendá-lo. Como o 
gerenciador de memória pode informar o kernel ? 

A solução para esse problema é ter uma tarefa de ker¬ 
nel que se comunica com o sistema de arquivos e com o 
gerenciador de memória por meio do mecanismo-padrão 
de mensagens e que também tenha acesso a todas as tabe¬ 
las do kernel. Essa tarefa, chamada tarefa de sistema, 
está na camada 2 na Figura 2-26 e funciona como as ou¬ 
tras tarefas que estudamos nesse capítulo. A única diferen¬ 
ça é que ela não controla qualquer dispositivo de E/S. Mas, 
como as tarefas de E/S, ela implementa uma interface, nesse 
caso não para o mundo exterior, mas para a parte mais 
interna do sistema. Ela tem os mesmos direitos concedidos 
às tarefas de E/S e é compilada com elas na imagem do 
kernel e faz mais sentido estudá-la aqui do que em qual¬ 
quer outro capítulo. 

A tarefa de sistema aceita 19 tipos de mensagens, mos¬ 
tradas na Figura 3-50. 0 programa principal da tarefa de 
sistema, sysjask (linha 14837), é estruturado como ou¬ 
tras tarefas. Ele recebe uma mensagem, despacha para o 
procedimento de serviço apropriado e, então, envia uma 
resposta. Agora veremos cada uma dessas mensagens e seus 
procedimentos de serviço. 


A mensagem SYS_PORKé utilizada pelo gerenciador de 
memória para informar o kernel de que um novo processo 
passou a existir. 0 kernel precisa saber disso para agendá- 
lo. A mensagem contém os números das entradas na tabe¬ 
la de processos correspondentes ao pai e ao filho. O geren¬ 
ciador de memória e o sistema de arquivos também têm 
tabelas de processos, com a entrada k referenciando o mes¬ 
mo processo em todas as três. Assim, o gerenciador de me¬ 
mória pode especificar apenas os números de entrada do 
pai e do filho, e o kernel saberá quais processos são indica¬ 
dos. 

0 procedimento do_fork (linha 14877) primeiro faz 
uma verificação (linha 14886) para ver se o gerenciador 
de memória está gerando lixo para o kernel. 0 teste utiliza 
uma macro, isoksusern, definida em proc.h, para testar se 
as entradas da tabela de processos para pai e filho são váli¬ 
das. Testes semelhantes são feitos pela maioria dos proce¬ 
dimentos de serviço em system.c. Isso é pura paranóia, mas 
uma pequena verificação de consistência interna não faz 
mal nenhum. Então, do_fork copia a entrada da tabela de 
processos do pai para a entrada do filho. Algumas coisas 
devem ser ajustadas aqui. 0 filho é liberado de quaisquer 
sinais pendentes para o pai, e o filho não herda o status de 
execução do pai. E, naturalmente, todas as informações de 
contabilidade do filho são configuradas como zero. 

Após um FORK, o gerenciador de memória aloca me¬ 
mória para o filho. O kernel deve saber onde o filho está 
localizado na memória para poder configurar os registra¬ 
dores de segmento adequadamente quando executar o fi¬ 
lho. A mensagem SYS_NEWMAP permite que o gerencia¬ 
dor de memória dê para o kernel o mapa de memória de 
qualquer processo. Essa mensagem também pode ser utili¬ 
zada depois que uma chamada de sistema BRK alterar o 
mapa. 

A mensagem é tratada por do_newmap (linha 14921), 
que deve primeiro copiar o novo mapa a partir do espaço 
de endereçamento do gerenciador de memória. O mapa não 
é contido na mensagem em si porque é muito extenso. Em 
teoria, o gerenciador de memória poderia informar o ker¬ 
nel de que o mapa está no endereço m, onde m é um ende¬ 
reço ilegal. Não se espera que o gerenciador de memória 
faça isso, mas o kernel verifica de qualquer jeito. O mapa é 
copiado diretamente para o campo p_map da entrada na 
tabela de processos correspondente que está obtendo o novo 
mapa. A chamada para alloc_segments extrai as informa¬ 
ções do mapa e carrega-as nos campos pjreg que armaze¬ 
nam os registradores de segmento. Isso não é complicado, 
mas os detalhes são dependentes do processador e são se¬ 
gregados em uma função a parte por essa razão. 

A mensagem SYS_NEWMAP é muito utilizada na ope¬ 
ração normal de um sistema MINIX. Uma mensagem se¬ 
melhante, SYSjSETMAP, é utilizada somente quando o sis¬ 
tema de arquivos é inicializado. Essa mensagem solicita 
uma transferência das informações do mapa de processo 
na direção oposta, do kernel para o gerenciador de memó¬ 
ria. Ela é executada por do_getmap (linha 14957). 0 có- 
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Tipo de mensagem 

De 

Significado 

SYS_FORK 

MM 

Um processo foi criado 

SYS_NEWMAP 

MM 

Instala um mapa de memória para um novo processo 

SYS_GETMAP 

MM 

O gerenciador de memória quer o mapa de memória de um processo 

SYS_EXEC 

MM 

Configura o ponteiro da pilha depois da chamada EXEC 

SYS_XIT 

MM 

Um processo saiu 

SYS_GETSP 

MM 

O gerenciador de memória quer o ponteiro da pilha de um processo 

SYS_TIMES 

FS 

O sistema de arquivos quer os tempos de execução de um processo 

SYS_ABORT 

Ambos 

Pane: o MINIX é incapaz de continuar 

SYS_SENDSIG 

MM 

Envia um sinal para um processo 

SYS_SIGRETURN 

MM 

Limpeza após a conclusão de um sinal 

SYS_KILL 

FS 

Envia sinal para um processo depois da chamada KILL 

SYS_ENDSIG 

MM 

Limpeza depois de um sinal do kernel 

SYS_COPY 

Ambos 

Copia dados entre processos 

SYS_VCOPY 

Ambos 

Copia múltiplos blocos de dados entre processos 

SYS_GBOOT 

FS 

Obter parâmetros de inicialização 

SYSJVIEM 

MM 

O gerenciador de memória quer o próximo trecho de memória física 

SYS_UMAP 

FS 

Converte endereço virtual em endereço físico 

SYS_TRACE 

MM 

Executa uma operação da chamada PTRACE 


Figura 3-50 Tipos de mensagem aceitos pela tarefa de sistema. (MM = gerenciador de memória; FS = sistema de arquivos) 


digo das duas funções é semelhante, diferindo principal¬ 
mente na troca dos argumentos de origem e de destino uti¬ 
lizados por cada função na chamada a phys_copy. 

Quando um processo faz uma chamada de sistema EXEC, 
o gerenciador de memória cria uma nova pilha, contendo 
os argumentos e o ambiente. Ele passa o ponteiro da pilha 
resultante para o kernel utilizando SYS_EXEC, a qual é tra¬ 
tada por do_exec (linha 14990). Depois da verificação nor¬ 
mal para um processo válido, há um teste do campo PR0C2 
na mensagem. Esse campo é utilizado aqui como sinaliza¬ 
dor para indicar se os passos da execução do processo estão 
sendo depurados e não tem nada a ver com identificar um 
processo. Se a depuração está em efeito, cause_sig é cha¬ 
mada para enviar um sinal SIGTRAP para o processo. Isso 
não tem as consequências normais desse sinal, que nor¬ 
malmente seriam terminar um processo e causar um dump 
de núcleo. No gerenciador de memória todos os sinais para 
um processo que está sendo depurado, exceto SIGKILL, são 
interceptados e fazem o processo sinalizado parar de modo 
que um programa de depuração, então, possa controlar sua 
execução posterior. 

A chamada de exec causa uma ligeira anomalia. 0 pro¬ 
cesso que invoca a chamada envia uma mensagem para o 
gerenciador de memória e bloqueia. Com outras chama¬ 
das de sistema, a resposta resultante desbloqueia-os. Com 
exec, não há nenhuma resposta, porque a imagem recen¬ 
temente carregada do núcleo não está esperando uma res¬ 


posta. Portanto, do_exec desbloqueia o próprio processo 
na linha 15009- A próxima linha torna a nova imagem 
pronta para executar, utilizando a função lock_ready que 
protege contra uma possível condição de corrida. Por fim, 
a string de comando é salva para que o processo possa ser 
identificado quando o usuário pressionar a tecla de função 
F1 para exibir o status de todos os processos. 

Os processos podem sair no MINIX tanto fazendo uma 
chamada de sistema EXIT, que envia uma mensagem para 
o gerenciador de memória, quanto sendo eliminandos por 
um sinal. Em ambos os casos, o gerenciador de memória 
informa o kernel por meio da mensagem SYSJKIT. 0 tra¬ 
balho é feito por dojdt (linha 15027), que é mais compli¬ 
cada do que talvez se espere. Cuidar das informações de 
contabilidade é simples e direto. 0 temporizador de alar¬ 
me, se houver um, é eliminado, armazenando um zero so¬ 
bre ele. E por essa razão que a tarefa de relógio sempre 
verifica quando um temporizador expirou para ver se qual¬ 
quer um ainda está interessado. A parte difícil de do_xit é 
que o processo pode estar enfileirado ao tentar enviar ou 
receber no momento em que foi eliminado. 0 código nas 
linhas 15056 a 15076 verifica essa possibilidade. Se o pro¬ 
cesso que está saindo for localizado na fila de mensagens 
de qualquer outro processo, ele é cuidadosamente removi¬ 
do. 

Em contraposição à mensagem anterior, que é ligeira¬ 
mente complicada, SYSjGEJSP é absolutamente trivial. Ela 
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é utilizada pelo gerenciador de memória para obter o valor 
do ponteiro de pilha atual para algum processo. Esse valor 
é necessário para as chamadas de sistema BRK e SBRK ve¬ 
rem se o segmento de dados e o segmento de pilha colidi¬ 
ram. 0 código está em do_getsp (linha 15089). 

Agora chegamos a um dos poucos tipos de mensagem 
utilizados exclusivamente pelo sistema de arquivos, 
SYS_TIMES. Ela é necessária para implementar a chamada 
de sistema TIMES, que retorna os tempos de contabilidade 
para o chamador. Tudo que dojimes (linha 15106) faz é 
colocar os tempos solicitados na mensagem de resposta. As 
chamadas para lock e unlock são utilizadas para proteger 
contra uma possível concorrência no acesso aos contado¬ 
res de tempo. 

Pode acontecer que o gerenciador de memória ou o sis¬ 
tema de arquivos descubra um erro que torna impossível 
continuar a operação. Por exemplo, na inicialização do 
primeiro, o sistema de arquivos vê que o superbloco no dis¬ 
positivo raiz foi fatalmente corrompido, ele entra em pane 
e envia uma mensagem SYS_ABORT para o kernel. Tam¬ 
bém é possível o superusuário forçar um retorno para o 
monitor de inicialização e/ou uma reinicialização utili¬ 
zando o comando reboot, que, por sua vez, executa uma 
chamada de sistema reboot. Em qualquer desses casos. a 
tarefa de sistema executa do_abort (linha 15131), que 
copia instruções para o monitor, se necessário, e, então, 
chama wreboot para completar o processo. 

A maior parte do trabalho de tratamento de sinais é fei¬ 
ta pelo gerenciador de memória, que verifica se o processo 
a ser sinalizado está ativado para detectar ou para ignorar o 
sinal, se o remetente do sinal estiver intitulado a fazer isso e 
assim por diante. Entretanto, o gerenciador de memória 
realmente não pode causar o sinal, o que requer colocar 
algumas informações na pilha do processo sinalizado. 

O tratamento de sinais anterior ao POSIX era problemá¬ 
tico, porque capturar um sinal restaurava a resposta, pa¬ 
drão para os sinais. Se o tratamento especial continuado 
de sinais subseqüentes for requerido, o programador não 
poderia garantir confiabilidade. Os sinais são assíncronos 
e um segundo sinal poderia muito bem chegar antes do 
tratamento ser reativado. 0 tratamento de sinal no estilo 
do POSix resolve esse problema, mas o preço é um meca¬ 
nismo mais complicado. O tratamento de sinal no antigo 
estilo poderia ser implementado pelo sistema operacional, 
empurrando algumas informações para a pilha do proces¬ 
so sinalizado, de maneira semelhante às informações em¬ 
purradas por uma interrupção. O programador, então, es¬ 
creveria um manipulador que terminaria com uma ins¬ 
trução de retorno, retirando da pilha as informações ne¬ 
cessárias para reassumir a execução. O POSix salva mais 
informações, quando um sinal é recebido, do que poderia 
ser tratado convenientemente dessa maneira. Há um tra¬ 
balho adicional a fazer mais tarde, antes de o processo si¬ 
nalizado poder reassumir o que estava fazendo. 0 gerenci¬ 
ador de memória, assim, precisa enviar duas mensagens 
para a tarefa de sistema para processar um sinal. A recom¬ 


pensa para esse esforço é um tratamento de sinais mais 
confiável. 

Quando um sinal está para ser enviado para um pro¬ 
cesso, a mensagem SYS_SENDS!G é enviada para a tarefa 
de sistema. Ela é tratada por do_sendsig (linha 15157). As 
informações necessárias para tratar sinais no estilo POSIX 
estão em uma estrutura sigcontext, que contém o conteú¬ 
do dos registradores do processador e uma estrutura sigfra- 
rne, com as informações sobre como sinais são tratados 
pelo processo. Essas duas estruturas necessitam de alguma 
inicialização, mas o trabalho básico de do_sendsig é sim¬ 
plesmente colocar as informações requeridas na pilha do 
processo sinalizado e ajustar o contador de programa e o 
ponteiro da pilha do processo sinalizado de modo que o 
código de tratamento de sinal seja executado da próxima 
vez que o agendador der permissão para o processo execu¬ 
tar. 

Quando um manipulador de sinais no estilo POSIX com¬ 
pleta seu trabalho, ele não retira da pilha o endereço onde 
a execução do processo interrompido é reassumida, como 
é o caso com sinais no estilo antigo. Ao escrever o manipu¬ 
lador, o programador escreve uma instrução de retomo (ou 
o equivalente na linguagem de alto nível), mas o trata¬ 
mento da pilha pela chamada sendsiü faz com que a ins¬ 
trução de retorno leve a execução de uma chamada de sis¬ 
tema SIGRETURN. O gerenciador de memória, então, en¬ 
via à tarefa de sistema uma mensagem S}’S_SIGRETURN. 
Isso é tratado por do_sigreturn (linha 15221), que copia a 
estrutura sigcontext de volta no espaço do kernel e, então, 
restaura os registradores do processo sinalizado. 0 proces¬ 
so interrompido reassumirá a execução no ponto onde foi 
interrompido da próxima vez que o agendador permitir que 
ele execute, mantendo qualquer tratamento de sinal espe¬ 
cial que tenha sido previamente configurado. 

A chamada de sistema sigreturn, diferentemente da 
maioria das outras discutidas nesta seção, não é requerida 
pelo POSIX. Ela é uma invenção do mintx, uma maneira 
conveniente de iniciar o processamento necessário quan¬ 
do um manipulador de sinal está completo. Os programa¬ 
dores não devem utilizar essa chamada; ela não será reco¬ 
nhecida por outros sistemas operacionais e, de qualquer 
maneira, não há nenhuma necessidade de referenciá-la 
explicitamente. 

Alguns sinais provêm de dentro da imagem do kernel 
ou são tratados por este antes de irem para o gerenciador 
de memória. Esses sinais incluem sinais outros que se ori¬ 
ginam de tarefas, como alarmes da tarefa de relógio ou 
sinais causados por pressionamentos de teclas detectados 
pela tarefa de terminal, assim como sinais causados por 
exceções (como divisão por zero ou instruções ilegais) de¬ 
tectados pela CPU. Os sinais que se originam do sistema de 
arquivos também são tratados primeiro pelo kernel. A men¬ 
sagem SYSJQLL é utilizada pelo sistema de arquivos para 
solicitar que tal tipo de sinal seja gerado. O nome é talvez 
um pouco enganoso. Isso não tem nada a ver com o trata¬ 
mento da chamada de sistema kill, utilizada por proces- 
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sos normais para enviar sinais. Essa mensagem é tratada 
por do_kill (linha 15276), que faz a verificação normal 
para uma origem válida da mensagem e, então, chama 
cause_sig para realmente passar o sinal para o processo. 
Os sinais originados no kernel também são passados por 
uma chamada para essa função, que inicia sinais envian¬ 
do uma mensagem KSIG para o gerenciador de memória. 

Sempre que o gerenciador de memória terminou com 
um desses sinais tipo KSIG, ele envia uma mensagem 
SYS_ENDSIG de volta para a tarefa de sistema. Essa men¬ 
sagem é tratada por dojmdsig (linha 15294), que decre- 
menta a contagem dos sinais pendentes, e, se alcançar zero, 
zera o bilSIG_PENDING pata o processo sinalizado. Se não 
houver outros sinalizadores ativados para indicar razões 
pelas quais o processo não deve ser executável, lock_ready 
é, então, chamada para permitir que o processo execute 
novamente. 

A mensagem SYS_COPYé a mais intensamente utiliza¬ 
da. Ela é necessária para permitir que o sistema de arqui¬ 
vos e o gerenciador de memória copiem as informações de 
e para processos de usuário. 

Quando um usuário faz uma chamada READ, o sistema 
de arquivos verifica seu cache para ver se tem o bloco ne¬ 
cessário. Se não tiver, ele envia uma mensagem à tarefa de 
disco apropriada para carregá-lo no cache. Então, o siste¬ 
ma de arquivos envia uma mensagem à tarefa de sistema 
dizendo-lhe para copiar o bloco para o processo de usuá¬ 
rio. No pior caso, sete mensagens são necessárias para ler 
um bloco; no melhor, quatro mensagens são necessárias. 


Ambos os casos são mostrados na Figura 3-51. Tais mensa¬ 
gens são uma fonte significativa de overhead no MINIX e 
são o preço pago pelo projeto altamente modular 

A propósito, nos 8088, que não tinham nenhuma pro¬ 
teção, seria muito fácil trapacear e deixar o sistema de ar¬ 
quivos copiar os dados para o espaço de endereço do cha- 
mador, mas isso teria transgredido o princípio do projeto. 
Qualquer pessoa com acesso a uma máquina assim tão 
antiga e que estivesse interessada em melhorar o desempe¬ 
nho do MINIX deve ver com cuidado esse mecanismo para 
avaliar quanto comportamento impróprio pode ser tolera¬ 
do para o ganho no desempenho. Naturalmente, esse re¬ 
curso para melhora do desempenho não está disponível em 
máquinas da classe Pentium com mecanismos de prote¬ 
ção. 

0 tratamento de uma solicitação SYS_COPYé simples e 
direto. Ele é feito por do_copy (linha 15316) e consiste em 
pouco mais que simplesmente extrair os parâmetros da 
mensagem e chamar phys_copy. 

Uma maneira de lidar com alguma ineficiência do 
mecanismo de passagem de mensagem é empacotar múl¬ 
tiplas solicitações em uma mensagem. A mensagem 
SYS_VCOPY faz isso. 0 conteúdo dessa mensagem é um 
ponteiro para um vetor especificando múltiplos blocos a 
serem copiados entre posições de memória. A função 
dojucopy (linha 15364) executa um laço, extraindo os 
endereços de origem e de destino e comprimentos de bloco 
e chamando phys_copy repetidamente até que todas as có¬ 
pias estejam completas. Isso é semelhante à capacidade de 



Figura 3-51 (a) 0 pior caso para ler um bloco exige sete mensagens, (b) 0 melhor caso para ler um bloco exige quatro mensagens. 
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dispositivos de disco para tratar múltiplas transferências 
com base em uma única solicitação. 

Há vários outros tipos de mensagem recebida pela tare¬ 
fa de sistema, a maioria das quais é bem simples. Duas 
dessas normalmente são utilizadas somente durante a ini¬ 
cialização do sistema. 0 sistema de arquivos envia uma 
mensagem SYS_GBOOT para solicitar os parâmetros de ini¬ 
cialização. Esses são uma estrutura. bparam_s. declarada 
em indude/minLx/boot.h, que permite que vários aspec¬ 
tos da configuração do sistema sejam especificados pelo 
programa monitor de inicialização antes de o MINIX ser 
iniciado. A função do_gboot (linha 15403) executa essa 
operação, que é somente uma cópia de uma parte da me¬ 
mória para outra. Também em tempo de inicialização, o 
gerenciador de memória envia à tarefa de sistema uma sé¬ 
rie de mensagens SYSJfEM solicitando a base e o tama¬ 
nho dos trechos de memória disponíveis. Do_mem (linha 
15424) trata essa solicitação. 

A mensagem SYSJUMAP é utilizada por um processo 
que não pertence ao kernel para solicitar o cálculo do en¬ 
dereço físico da memória para um endereço virtual dado. 
Do_umap (linha 15445) executa isso chamando umap, 
que é a função chamada no interior do kernel para tratar 
essa conversão. 

0 último tipo de mensagem que discutiremos é 
SYS_TRACE, que suporta a chamada de sistema PTRACE, 
utilizada para depuração. Depuração não é uma função 
fundamental do sistema operacional, mas o suporte do sis¬ 
tema operacional pode torná-la mais fácil. Com a ajuda 
do sistema operacional, um depurador pode examinar e 
modificar a memória utilizada por um processo sob teste, 
assim como o conteúdo dos registradores do processador 
que são armazenados na tabela de processos sempre que o 
programa de depuração não está executando. 

Normalmente, um processo executa até que bloqueia 
esperando E/S ou gasta um quantum de tempo. A maioria 
dos projetos de CPU também oferece uma maneira de li¬ 
mitar a execução de um processo a apenas uma única ins¬ 
trução, ou pode fazer-se com que ele execute somente até 
que uma instrução particular seja alcançada, colocando 
um ponto de interrupção. Tirar proveito de tais facilida¬ 
des torna possível uma análise detalhada do programa. 

Há 11 operações que podem ser executadas utilizando 
PTRACE. Algumas são executadas totalmente pelo gerenci¬ 
ador de memória, mas na maioria delas o gerenciador de 
memória envia uma mensagem SYS_TRACE à tarefa de sis¬ 
tema, que, então, chama dojrace (linha 15467). Essa fun¬ 
ção implementa um switch no código de operação de de¬ 
puração. As operações são, em geral, simples. Um bit 
P_STOP na tabela de processos é utilizado pelo minix para 
reconhecer que a depuração está em progresso e é ligado 
pelo comando para parar o processo (caso T_ST0P) ou ze- 
rado para reiniciá-lo (caso T_RESUME). A depuração de¬ 
pende do suporte de hardware e, em processadores Intel, é 
controlada por um bit no registrador de sinalizadores da 
CPU. Quando o bit é ligado, o processador executa somen¬ 
te uma instrução, então, gera uma exceção SIGTRAP. Como 


já foi mencionado, o gerenciador de memória pára um pro¬ 
grama que está sendo depurado quando um sinal é envia¬ 
do para ele. Esse TRACEBIT é tratado pelos comandos 
TJSTOP e T_STEP. Os pontos de interrupção podem ser con- 
figurados de duas maneiras: utilizando o comando 
T_SETINS para substituir uma instrução por um código 
especial que gera um SIGTRAP, ou utilizando o comando 
T_SETUSER para modificar registradores especiais de pon¬ 
to de interrupção. Em qualquer tipo de sistema para o qual 
o minix pode ser portado, provavelmente será possível im¬ 
plementar um depurador utilizando técnicas similares, mas 
portar tais funções exigirá estudo do hardware particular. 

A maioria dos comandos executados por dotrace retor¬ 
na ou modifica valores no espaço de dados ou de texto do 
processo em depuração ou em sua entrada da tabela de 
processos, e o código é simples e direto. Alterar certos regis¬ 
tradores e certos bits dos sinalizadores da CPU é algo muito 
inseguro para ser permitido; então, há muitas verificações 
no código que trata o comando T_SETUSER para evitar es¬ 
sas operações. 

No fim de system.c estão vários procedimentos utilitá¬ 
rios, usados em vários lugares por todo o kernel. Quando 
uma tarefa precisa causar um sinal (p. ex., a tarefa de re¬ 
lógio precisa causar um sinal SIGALRM ou a tarefa de ter¬ 
minal precisa causar um sinal de SIGIXT), ela chama 
cause_sig (linha 15586). Esse procedimento liga um bit 
no campo p_pmding na entrada da tabela de processos 
referente ao processo a ser sinalizado e, então, verifica se o 
gerenciador de memória atualmente está esperando uma 
mensagem àeANY, isto é, se ele está desocupado e esperan¬ 
do a próxima solicitação processar. Se estiver desocupado, 
inform é chamada para dizer para o gerenciador de me¬ 
mória tratar o sinal. 

Inform (linha 15627) é chamada somente depois de 
uma verificação de que o gerenciador de memória não está 
ocupado, como descrito acima. Além da chamada a partir 
de cause_sig, ela é chamada a partir de minijrec (em 
proc.c) sempre que o gerenciador de memória bloqueia e 
há sinais pendentes do kernel. Inform cria uma mensa¬ 
gem do tipo KSIG e envia para o gerenciador de memória. A 
tarefa ou o processo que chama causejsig continua exe¬ 
cutando logo que a mensagem é copiada para o buffer de 
recebimento do gerenciador de memória. Ela não espera o 
gerenciador de memória executar, como seria o caso se o 
mecanismo de envio normal, que faz o remetente bloque¬ 
ar, fosse utilizado. Antes de retornar, entretanto, inform 
chama lock_pick_proc, que agenda o gerenciador de me¬ 
mória para executar. Como as tarefas têm prioridade supe¬ 
rior aos servidores, o gerenciador de memória não executa 
até que todas as tarefas sejam satisfeitas. Quando a tarefa 
sinalizadora termina, o agendador será iniciado. Se o ge¬ 
renciador de memória for o processo com prioridade de 
execução mais alta, ele executará e processará o sinal. 

Umap (linha 15658) é um procedimento genérico útil 
que mapeia um endereço virtual para um endereço físico. 
Como observamos, ele é chamado por do_umap, que ser¬ 
ve a mensagem SYSJUMAP. Seus parâmetros são um pon- 
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teiro para a entrada da tabela de processos referente ao pro¬ 
cesso ou tarefa cujo espaço virtual de endereço está para 
ser mapeado, um sinalizador que especifica o segmento de 
texto, dados ou pilha, o próprio endereço virtual e uma 
contagem de bytes. A contagem de bytes é útil porque umap 
verifica se o buffer inteiro iniciando no endereço virtual 
está dentro do espaço de endereço do processo. Para fazer 
isso, ele deve saber o tamanho do buffer. A contagem de 
bytes não é utilizada para o mapeamento em si, apenas 
para verificação. Todas as tarefas que copiam dados para 
ou do espaço do usuário calculam o endereço físico do bu¬ 
ffer, utilizando umap. Para drivers de dispositivo, é conve¬ 
niente ser capaz de obter os serviços de umap, iniciando 
com o número de processo em vez de um ponteiro para 
uma entrada da tabela de processos. Numap (linha 15697) 
faz isso. Ele chama do_newmap para converter seu pri¬ 
meiro argumento e, então, chama umap. 

A última função definida em sys/em.céalloc_segments 
(linha 15715). Ela é chamada por do_neu'map. E tam¬ 
bém é chamada pela rotina main do kernel durante a ini¬ 
cialização. Essa definição é muito dependente de hardwa¬ 
re. Ela pega as atribuições de segmento que estão registra¬ 
das em uma entrada da tabela de processos e trata os regis¬ 
tradores e os descritores que o processador Pentium utiliza 
para suportar segmentos protegidos de nível do hardware. 

3.11 RESUMO 

Entrada/saída é um tema freqüentemente negligenci¬ 
ado, mas importante. Uma parte significativa de qualquer 
sistema operacional cuida da E/S. Iniciamos vendo o har¬ 
dware de E/S, e a relação dos dispositivos de E/S com as 
controladoras de E/S, que são o que o software precisa tra¬ 
tar. Então vimos os quatro níveis de software de E/S: as ro¬ 
tinas de interrupção, os drivers de dispositivo, o software 
de E/S independente de dispositivo e as bibliotecas de E/S. 
e os spoolers que executam no espaço do usuário. 

Em seguida, estudamos o problema dos impasses e como 
ele pode ser abordado. Um impasse ocorre quando, em um 
grupo de processos, foi concedido a cada um acesso exclu¬ 
sivo a alguns recursos e cada um ainda quer outro recurso 
que pertence a outro processo no grupo. Todos eles são blo¬ 


queados e nenhum jamais executará novamente. 0 im¬ 
passe pode ser prevenido estruturando-se o sistema de modo 
que isso nunca possa ocorrer, por exemplo, permitindo-se 
que um processo aloque somente um recurso em qualquer 
instante. 0 impasse também pode ser evitado examinan¬ 
do-se cada solicitação de recurso para ver se ela conduz a 
uma situação em que o impasse é possível (um estado in¬ 
seguro) e negar ou retardar aquelas que levam a proble¬ 
mas. 

Os drivers de dispositivo no MiXix são implementados 
como processos embutidos no kernel. Vimos o driver de 
disco de RAM, o de disco rígido, o de relógio e o de termi¬ 
nal. A tarefa de alarme síncrono e a tarefa de sistema não 
são drivers de dispositivo mas são estruturalmente muito 
semelhantes a um. Cada uma dessas tarefas tem um laço 
principal que recebe solicitações, processa-as e, por fim, 
envia de volta respostas para informar o que aconteceu. 
Todas as tarefas estão localizadas no mesmo espaço de en¬ 
dereço. As tarefas de disco de RAM, de disco rígido e de dri¬ 
ver de disquete utilizam uma única cópia do mesmo laço 
principal e também compartilham funções comuns. Con¬ 
tudo, cada uma é um processo independente. Vários termi¬ 
nais diferentes, utilizando o console do sistema, as linhas 
seriais e as conexões de rede são suportados por uma única 
tarefa de terminal. 

Os drivers de dispositivo têm relacionamentos variá¬ 
veis com o sistema de interrupções. Os dispositivos que po¬ 
dem completar seu trabalho rapidamente, como o disco de 
RAM e o dispositivo de vídeo mapeado em memória, não 
utilizam interrupções de modo algum. A tarefa do driver 
de disco rígido faz a maior parte do seu trabalho no pró¬ 
prio código da tarefa, e os manipuladores de interrupções 
simplesmente informam o status de retorno. 0 próprio 
manipulador de interrupções de relógio faz diversas opera¬ 
ções de contabilidade e somente envia uma mensagem para 
a tarefa de relógio quando há algum trabalho que não pode 
ser feito pelo manipulador. 0 manipulador de interrupções 
de teclado bufferíza a entrada e nunca envia uma mensa¬ 
gem para sua tarefa. Em vez disso, ele muda uma variável 
inspecionada pelo manipulador de interrupções de reló¬ 
gio; este último envia uma mensagem para a tarefa de ter¬ 
minal. 


EXERCÍCIOS 


1. Imagine que os avanços na tecnologia dos chips tornem pos¬ 
sível colocar uma controladora inteira, incluindo toda a ló¬ 
gica de acesso de barramento. em um chip de baixo custo. 
Como isso afetará o modelo da Figura 3-1? 

2. Se uma controladora de disco grava os bytes que recebe da 
memória de disco tão rapidamente quanto ela os recebe, sem 
nenhuma bufferização interna, a intercalação é concebivel- 
mente útil? Discuta. 


3. Com base na velocidade de rotação e na geometria dos dis¬ 
cos, quais são as taxas de bit para transferências entre o pró¬ 
prio disco e o buffer da controladora para um disquete e para 
um disco rígido? Como isso se compara com outras formas 
de E/S (linhas seriais e redes)? 

4. Um disco é duplamente intercalado, como na Figura 3-4(c). 
Ele tem oito setores de 512 bytes por trilha e uma velocidade 
de rotação de 300rpm. Quanto tempo ele leva para ler todos 
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os setores de uma trilha em ordem, supondo que o braço já 
esteja corretamente posicionado e 1/2 rotação seja necessá¬ 
ria para obter o setor 0 sob o cabeçote? 0 que é a taxa de 
transmissão de dados? Agora repita o problema para um disco 
não-intercalado com as mesmas características. Quanto a 
taxa de transmissão de dados degrada devido à intercala¬ 
ção? 

5. 0 multiplexador de terminal DM-11, que foi utilizado no 
PDP-11, há muitos e muitos anos, fazia uma amostragem 
de cada linha (half duplex) de terminal a sete vezes a taxa 
de transmissão de dados (baud rate) para ver se o bit de 
entrada era um 0 ou um 1. A amostragem da linha levava 
5,7 microssegundos. Quantas linhas de 1.200 bauds o DM- 
11 podia suportar? 

6. Uma rede local é utilizada como segue. O usuário emite uma 
chamada de sistema para gravar pacotes de dados na rede. 
O sistema operacional, então, copia os dados para um buffer 
do kernel. Então, ele copia os dados para a controladora de 
rede. Quando todos os bytes estão seguramente dentro da 
controladora, eles são enviados pela rede a uma taxa de 10 
megabits/s. A controladora de rede receptora armazena cada 
bit em um microssegundo depois de ele ser enviado. Quan¬ 
do o último bit chega, a CPU de destino sofre uma interrup¬ 
ção. 0 kernel copia o pacote recém-chegado para um buffer 
do kernel para inspecioná-lo. Uma vez que tenha descober¬ 
to o usuário a quem o pacote destina-se, o kernel copia os 
dados para o espaço do usuário. Se supormos que cada in¬ 
terrupção e seu processamento associado leva lms, que os 
pacotes são de 1024 bytes (ignorando os cabeçalhos) e que 
copiar um byte leva 1 microsegundo, qual será a taxa máxi¬ 
ma em que um processo pode transmitir dados para o ou¬ 
tro? Suponha que o remetente esteja bloqueado até que o 
trabalho tenha terminado no lado do receptor e que um avi¬ 
so de reconhecimento seja retornado. Para simplificar, su¬ 
ponha que o tempo para obter o aviso de reconhecimento de 
volta é tão pequeno que pode ser ignorado. 

7. O que é “independência de dispositivo”? 

8. Em qual das quatro camadas de software de E/S é feito cada 
uma das seguintes operações: 

(a) Calcular a trilha, o setor e o cabeçote para uma leitura 
de disco 

(b) Manter um cache de blocos recentemente utilizados. 

(c) Gravar comandos nos registradores do dispositivo 

(d) Verificar se o usuário tem permissão para utilizar o 
dispositivo. 

(e) Converter inteiros binários em ASCII para impressão. 

9. Por que arquivos de saída para a impressora normalmente 
sofrem spool em disco antes de serem impressos? 

10. Considere a Figura 3-8. Suponha que no passo (o) C tenha 
solicitado S em vez de R. Isso levaria a um impasse? E su¬ 
pondo que ele tenha solicitado tanto S quanto R? 

11. Faça um cuidadoso exame da Figura 3-11 (b). Se Suzanne 
solicitar mais uma unidade, isso levaria a um estado seguro 
ou a um estado inseguro? E se a solicitação viesse de Marvin 
em vez de Suzanne? 

12. Todas as trajetórias na Figura 3-12 são horizontais ou verti¬ 
cais. Você pode vislumbrar qualquer circunstância em que 
trajetórias diagonais também sejam possíveis? 


13. Suponha que o processo na Figura 3-13 solicite a última 
unidade de fita. Essa ação conduz a um impasse? 

14. Um computador tem seis unidades de fita, com n processos 
competindo por elas. Cada processo pode solicitar duas uni¬ 
dades. Para quais valores de n o sistema ficaria livre de im¬ 
passes? 

15. Um sistema pode estarem um estado que não seja nem um 
estado de impasse nem um estado seguro? Se pode, dê um 
exemplo. Se não, prove que todos os estados são ou um esta¬ 
do de impasse ou um estado seguro. 

16. Um sistema distribuído que utiliza caixas de correio tem duas 
primitivas IPC, send e receive. A última primitiva especifi¬ 
ca um processo do qual deve receber e bloqueia se nenhuma 
mensagem desse processo estiver disponível, mesmo que 
possam estar sendo esperadas mensagens de outros proces¬ 
sos. Não há recursos compartilhados, mas os processos pre¬ 
cisam comunicar-se freqüentemente sobre outros assuntos. 
0 impasse é possível? Discuta. 

17. Em um sistema de transferência eletrônica de fundos, há 
centenas de processos idênticos que trabalham como segue. 
Cada processo lê uma linha de entrada especificando uma 
quantidade de dinheiro, a conta a ser creditada e a conta a 
ser debitada. Então, ele bloqueia ambas as contas e transfe¬ 
re o dinheiro, liberando os bloqueios quando tiver termina¬ 
do. Com muitos processos executando em paralelo, há um 
perigo muito real de que tendo bloqueado a conta.v ele será 
incapaz de bloquear y porquej 1 foi bloqueado por um pro¬ 
cesso agora esperando x. Esboce um esquema que evite im¬ 
passes. Não libere um registro de conta até que você tenha 
completado as transações. (Em outras palavras, não são per¬ 
mitidas soluções que bloqueiam uma conta e, então, libe¬ 
ram-na imediatamente se a outra estiver bloqueada). 

18. O algoritmo do banqueiro está sendo executado em um sis¬ 
tema com m classes de recursos e « processos. No limite de 
grandes m en,o número de operações que devem ser exe¬ 
cutadas para verificar a segurança de um estado é proporci¬ 
onal a m“ n b . Quais são os valores de a e b ? 

19. A Cinderela e o Príncipe estão divorciando-se. Para dividir 
sua propriedade, eles concordaram no seguinte algoritmo. 
Toda manhã, cada um deles pode enviar uma carta para o 
advogado do outro solicitando um item das propriedades. 
Como leva um dia para as cartas serem entregues, eles con¬ 
cordaram que se ambos descobrirem que pediram o mesmo 
item no mesmo dia, no dia seguinte eles enviarão uma car¬ 
ta cancelando a solicitação. Entre suas propriedades, estão 
seu cão, Woofer, a casinha de Woofer, seu canário, Tweeter. e 
a gaiola deste último. Os animais amam suas casas, então, 
foi concordado que qualquer divisão de propriedade que se¬ 
parasse um animal de sua casa seria inválida, exigindo que 
a divisão recomeçasse do zero. Tanto o Príncipe como a Cin¬ 
derela querem desesperadamente seu cão Woofer. Assim, eles 
saem em férias (separados), tendo cada um programado um 
computador pessoal para tratar a negociação. Quando eles 
voltam das férias, os computadores ainda estão negociando. 
Por quê? 0 impasse é possível? É possível ocorrer fome (es¬ 
perar eternamente) ? Discuta. 

20. O formato da mensagem da Figura 3-15 é utilizado para 
enviar mensagens de solicitação para drivers de dispositi¬ 
vos de bloco. Que campos poderiam ser omitidos, se é que 
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algum poderia ser omitido, em mensagens para dispositivos 
de caractere? 

21. Chegam ao driver de disco solicitações pelos cilindros 10, 
22, 20, 2,40, 6 e 38, nessa ordem. Uma busca leva 6ms por 
cilindro movido. Quanto tempo de busca é necessário para: 

(a) Primeiro a entrar, primeiro a ser servido. 

(b) Cilindro mais próximo em seguida 

(c) Algoritmo do elevador (inicialmente movendo-se para 
cima). 

Em todos os casos, o braço está inicialmente no cilindro 20. 

22. Um vendedor de computadores pessoais, em visita a uma 
universidade no sudoeste de Amsterdã, alardeava ao abor¬ 
dar um cliente que sua companhia tinha dedicado esforço 
substancial para tomar sua versão do UNIX mais veloz. Como 
exemplo, ele apontou que seu driver de disco utilizava o 
algoritmo do elevador e também enfileirava múltiplas soli¬ 
citações dentro de um cilindro pela ordem dos setores. Um 
aluno, Harry Hacker, ficou impressionado e comprou um. 
Levou-o para casa e escreveu um programa para ler aleato¬ 
riamente 10.000 blocos ao longo do disco. Para sua surpre¬ 
sa, o desempenho que ele mediu era idêntico ao que seria 
esperado do algoritmo primeiro a entrar, primeiro a ser ser¬ 
vido. O vendedor estava mentindo? 

23- Um processo UNIX tem duas partes — a parte do usuário e a 
parte do kernel. A parte do kernel é como uma sub-rotina 
ou uma co-rotina? 

24. O manipulador de interrupções de relógio em um certo com¬ 
putador exige 2ms (incluindo o overhead da comutação de 
processos) por tique de relógio. O relógio executa em 60Hz. 
Que fração da CPU é dedicada ao relógio? 

2 5. Dois exemplos de temporizadores watchdog foram dados no 
texto: sincronização da inicialização do motor de disquete e 
permissão para retorno de carro em terminais de impressão. 
Dê um terceiro exemplo. 

26. Por que os terminais RS-232 são baseados em interrupções, 
mas os terminais mapeados em memória não são? 

27. Considere o modo como um terminal funciona. O driver áí. 
saída a um caractere e, então, bloqueia. Quando o caractere 
é impresso, uma interrupção ocorre, e uma mensagem é en¬ 
viada para o driver bloqueado, que dá saída para o próximo 
caractere e, então, bloqueia novamente. Se o tempo de pas¬ 
sagem de uma mensagem, saída de um caractere e bloqueio 
é 4ms, esses métodos funcionam bem em linhas de 110 bau- 
ds ? E em linhas de 4800 baudsl 

28. Um terminal de mapa de bits contém 1.200 por 800 pixels. 
Para rolar uma janela, a CPU (ou controladora) deve mo¬ 
ver todas as linhas de texto para cima copiando seus bits de 
uma parte da RAM de vídeo para outra. Se uma janela em 
particular tiver 66 linhas de altura por 80 caracteres (5280 
caracteres, no total) e a caixa de caractere tiver 8 pixels de 
largura por 12 pixels de altura, quanto tempo é necessário 
para rolar a janela inteira a uma velocidade de cópia de 
500ns por byte? Se todas as linhas tiverem 80 caracteres de 
comprimento, qual é a taxa de transmissão de dados (baud 
rate) equivalente do terminal? Colocar um caractere na tela 
leva 50ms. Agora calcule a taxa de transmissão de dados 
para o mesmo terminal colorido, com 4 b\\s,/pixel. (Colocar 
um caractere na tela agora toma 200ms.) 


29- Por quê os sistemas operacionais oferecem caracteres de es¬ 
cape como CTRL-Y no MINIX? 

30. Depois de receber um caractere DEL (sigint), o driver do 
MINIX descarta toda a saída atualmente enfileirada para o 
terminal envolvido. Por quê? 

31. Muitos terminais RS-232 têm seqüências de escape para ex¬ 
cluir a linha atual e mover para cima uma linha todas as 
linhas embaixo da linha atual. Como você acha que esse 
recurso está implementado dentro do terminal? 

32. No monitor colorido original do IBM PC, escrever na RAM 
de vídeo em qualquer momento que não durante o retraço 
vertical do feixe do CRT causava manchas que apareciam 
por toda a tela. Uma imagem de tela tem 25 por 80 caracte¬ 
res, cada um dos quais se ajusta em uma caixa de 8 x 8 
pixels. Cada linha de 640 pixels é desenhada em uma única 
varredura horizontal do feixe, o que leva 63,6ms, incluindo 
o retraço horizontal. A tela é redesenhada 60 vezes por se¬ 
gundo, cada uma das quais requer o período de um retraço 
vertical para fazer o feixe voltar ao topo. Que fração de tem¬ 
po dispõe a RAM de vídeo para gravar? 

33. Escreva um driver gráfico para o monitor IBM colorido, ou 
algum outro monitor de mapa de bits conveniente. 0 driver 
deve aceitar comandos para ligar e para limparptvefc indi¬ 
viduais, para mover retângulos pela tela e para quaisquer 
outros recursos que você acredita serem interessantes. Pro¬ 
gramas do usuário fazem interface com o driver, abrindo/ 
dev/graphics e gravando comandos aí. 

34. Modifique o driver de disquete do mlntx para fazer cache de 
uma trilha por vez. 

35. Implemente um driver de disquete que funcione como um 
dispositivo de caractere, em vez de bloco, para pular o cache 
de blocos do sistema de arquivos. Dessa maneira, os usuá¬ 
rios podem ler grandes trechos de dados do disco, que são 
“DMAdos” diretamente para espaço do usuário, favorecen¬ 
do significativamente o desempenho. Esse driver seria de 
interesse principalmente para programas que precisam ler 
os bits brutos no disco, sem considerar o sistema de arqui¬ 
vos. Os verificadores dos sistemas de arquivos entram nessa 
categoria. 

36. Implemente a chamada de sistema PROFIL do UNIX, que está 
faltando no MINIX. 

37. Modifique o driver de terminal de modo que além de ter 
uma tecla especial para apagar o caractere anterior, haja 
uma tecla para apagar a palavra anterior. 

38. Um novo dispositivo de disco rígido com mídia removível 
foi adicionado a um sistema MINIX. Esse dispositivo deve al¬ 
cançar a velocidade de rotação toda vez que as mídias são 
trocadas, e o laço para isso é bem longo. Já se sabe que as 
trocas de mídia serão feitas com freqüência enquanto o sis¬ 
tema estiver executando. De repente, a rotina waitfor em 
at_wini.c torna-se insatisfatória. Projete uma nova rotina 
waitfor em que, se o padrão de bits sendo esperado não for 
encontrado depois de 1 segundo de espera ativa, o código 
entrará em uma fase em que a tarefa de disco irá dormir por 
1 segundo, testar a porta e voltar a dormir durante outro 
segundo até que o padrão buscado seja encontrado ou o 
período predefinido TIMEOUT expire. 



4 


Gerenciamento 
de Memória 


A memória é um recurso importante que deve ser ge¬ 
renciado com cuidado. Enquanto o computador domesti¬ 
co médio hoje em dia tem 50 vezes mais memória do que o 
IBM 7034, 0 maior computador no mundo no início da 
década de 60 , os programas estão crescendo tão rapida¬ 
mente quanto as memórias. Parafraseando a lei de Par- 
kinson,* poderíamos dizer que “os programas tendem a ex¬ 
pandir até ocupar toda a memória disponível para arma¬ 
zená-los”. Neste capítulo, estudaremos como 0 sistema 
operacional gerencia a memória. 

Idealmente, 0 que todo programador gostaria de ter à 
disposição é uma memória rápida e infinitamente grande 
que também fosse não-volátil, isto é, que não perdesse seu 
conteúdo quando a energia elétrica cai. E já que estamos 
divagando, por que também não pedir para que fosse bem 
barata? Infelizmente, a tecnologia ainda não oferece esse 
tipo de memória. A maioria dos computadores, portanto, 
tem uma hierarquia de memória, com uma pequena 
quantidade de memória de cache volátil, muito rápida e 
cara, alguns megabytes de memória principal volátil 
(RAM), de velocidade e preço médios, além de centenas ou 
milhares de megabytes de armazenamento em disco, não- 
volátil, lento e barato. 0 trabalho do sistema operacional é 
coordenar como essas memórias são utilizadas. 

A parte do sistema operacional que gerencia a hierar¬ 
quia de memória é chamada gerenciador de memória. 


‘N. de T. Observações satíricas propostas como leis econômicas, especi¬ 
almente "0 trabalho tende a aumentar até ocupar todo o tempo dispo¬ 
nível para sua conclusão". 0 nome provém do seu autor, o historiador 
britânico Cyril Northcote Parkinson (1909-1993). famoso por seus tra¬ 
balhos humorísticos que ridicularizavam a ineficiência das burocra¬ 
cias. 


Seu trabalho é controlar que partes da memória estão em 
uso e que partes não estão, alocar memória para processos 
quando eles necessitarem e desalocar quando eles termi¬ 
narem, e gerenciar a troca entre a memória principal e o 
disco quando a memória principal é muito pequena para 
armazenar todos os processos. 

Neste capítulo, investigaremos diversos esquemas de 
gerenciamento de memória, variando dos muito simples 
aos altamente sofisticados. Começaremos do princípio e 
veremos primeiro o sistema de gerenciamento de memória 
mais simples possível e, então, gradualmente avançaremos 
para aqueles cada vez mais elaborados. 

4.1 GERENCIAMENTO BÁSICO DE 
MEMÓRIA 

Os sistemas de gerenciamento de memória podem ser 
divididos em duas classes: aqueles que movem processos 
de um lado para outro entre a memória principal e o disco 
durante execução (fazendo troca e paginação) e aqueles 
que não o fazem. Os últimos são mais simples; então, va¬ 
mos estudá-los primeiro. Mais adiante neste capítulo, 
examinaremos troca e paginação. Ao longo de todo este 
capítulo, o leitor deve manter em mente que troca e pagi¬ 
nação são em grande parte artefatos causados pela falta de 
memória principal suficiente para armazenar todos os pro¬ 
gramas simultaneamente. À medida que a memória prin¬ 
cipal fica mais barata, os argumentos a favor de um tipo 
de esquema de gerenciamento de memória ou outro po¬ 
dem tornar-se obsoletos — a menos que os programas 
aumentem mais rapidamente do que o preço da memória 
diminui. 
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4.1.1 Monoprogramação sem Troca ou 
Paginação 

0 esquema mais simples possível de gerenciamento de 
memória é executar somente um programa por vez, com¬ 
partilhando a memória entre esse programa e o sistema 
operacional. Três variações desse tema são mostradas na 
Figura 4-1.0 sistema operacional pode estar na parte infe¬ 
rior da memória em RAM ( Random Access Memory , Me¬ 
mória de Acesso Aleatório), como mostrado na Figura 4- 
1 (a), ou pode estarem ROM (Read-Only Memory , Memó¬ 
ria Apenas de Leitura) na parte superior da memória, como 
mostrado na Figura 4-1 (b), ou os drivers de dispositivo 
podem estar na parte superior da memória em uma ROM e 
o restante do sistema em RAM na parte inferior, como mos¬ 
trado na Figura 4-1 (c). 0 último modelo é utilizado por 
pequenos sistemas MS-DOS, por exemplo. No IBM PC, a parte 
do sistema na ROM é chamada BIOS (Basic Input Output 
System , Sistema Básico de Entrada e Saída). 

Quando o sistema está organizado dessa maneira, so¬ 
mente um processo por vez pode estar executando. Logo 
que o usuário digita um comando, o sistema operacional 
copia o programa solicitado do disco para a memória e 
executa-o. Quando o processo termina, o sistema operaci¬ 
onal exibe um aviso de comando e espera um novo co¬ 
mando. Quando recebe o comando, ele carrega um novo 
programa na memória, sobrepondo o primeiro 

4.1.2 Multiprogramação com Partições 
Fixas 

Embora a monoprogramação seja, às vezes, utilizada 
em computadores pequenos com sistema operacional sim¬ 
ples, com freqüência é desejável permitir que múltiplos pro¬ 
cessos executem simultaneamente. Em sistemas de com¬ 
partilhamento de tempo, ter múltiplos processos na me¬ 
mória simultaneamente significa que quando um proces¬ 


so é bloqueado esperando a E/S acabar, outro pode utilizar 
a CPU. Assim, a multiprogramação aumenta a utilização 
da CPU. Entretanto, mesmo em computadores pessoais e' 
freqtientemente útil ser capaz de executar dois ou mais pro¬ 
gramas ao mesmo tempo. 

A maneira mais fácil de alcançar a multiprogramação 
é simplesmente dividir a memória em n partições (possi¬ 
velmente desiguais). Esse particionamento pode ser feito, 
por exemplo, manualmente quando o sistema é iniciado. 

Quando um job chega, pode ser colocado na fila de 
entrada da menor partição capaz de armazená-lo. Uma vez 
que as partições são fixas nesse esquema, qualquer espaço 
em uma partição não-utilizada por um job é perdido. A 
Figura 4-2 (a) apresenta um esquema desse sistema de par¬ 
tições fixas e de filas de entrada separadas. 

A desvantagem de classificar os jobs de entrada em filas 
separadas toma-se aparente quando a fila para uma parti¬ 
ção grande está vazia, mas a fila para uma partição peque¬ 
na está cheia, como é o caso para as partições 1 e 3 na 
Figura 4-2(a). Uma organização alternativa é manter uma 
fila única como na Figura 4-2 (b). Sempre que uma parti¬ 
ção torna-se livre, o job mais próximo do início da fila que 
se ajusta na partição vazia poderia ser carregado nela e 
executado. Uma vez que é indesejável desperdiçar uma 
partição grande com um job pequeno, uma estratégia di¬ 
ferente é pesquisar a fila de entrada inteira sempre que uma 
partição tomar-se livre e selecionar o maior job que se ajus¬ 
ta. Note que o último algoritmo discrimina jobs pequenos 
porque estes não merecem ter uma partição inteira, ao passo 
que normalmente é desejável dar o melhor serviço aos 
jobs pequenos (que supostamente são interativos), não o 
pior. 

Uma saída é dispor de pelo menos uma partição peque¬ 
na, a qual permitirá que jobs pequenos sejam executados 
sem alocar uma partição grande para eles. 

Outra abordagem é estabelecer uma regra determinan¬ 
do que um job elegível para executar não pode ser ignora- 
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Figura 4-1 Três maneiras simples de organizar memória com um sistema operacional e com um 
processo de usuário. Também existem outras possibilidades. 
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Figura 4-2 (a) Partições fixas de memória com filas separadas para cada partição, (b) Partições 

fixas de memória com uma única fila de entrada. 


do mais que k vezes. Cada vez que é ignorado, ele ganha 
um ponto. Quando adquiriu k pontos, ele não pode ser ig¬ 
norado novamente. 

Esse sistema, com partições fixas definidas pela manhã 
pelo operador e não alteradas depois, foi utilizado por 
mainframe s IBM OS /360 de grande porte durante muitos 
anos. Ele foi chamado MFT (Multiprogramação com um 
número Fixo de Tarefas ou OS/MFT). Ele é simples de en¬ 
tender e igualmente simples de implementar: os jobs que 
chegam são enfileirados ate' que uma partição adequada 
esteja disponível, momento em que 0 job é carregado nes¬ 
sa partição e executa até a sua conclusão. Hoje em dia, 
poucos sistemas operacionais suportam esse modelo, se é 
que algum suporta. 

Realocação e Proteção 

A multiprogramação introduz dois problemas essenci¬ 
ais que devem ser resolvidos — realocação e proteção. Olhe 
na Figura 4-2. Na figura está claro que jobs diferentes se¬ 
rão executados em endereços também diferentes. Quando 
um programa é vinculado (i. e., 0 programa principal, pro¬ 
cedimentos de usuário gravado, e procedimentos de bibli¬ 
oteca são combinados em um único espaço de endereço), 
0 linkeditor deve saber em que endereço 0 programa deve 
começar na memória. 

Por exemplo, suponha que a primeira instrução seja 
uma chamada para um procedimento no endereço abso¬ 
luto 100 dentro do arquivo binário, produzido pelo link¬ 
editor. Se esse programa for carregado na partição 1, essa 
instrução saltará para 0 endereço absoluto 100, que está 
dentro do sistema operacional. O que é necessário é uma 


chamada para 100K + 100. Se 0 programa for carregado 
na partição 2, ele executará como uma chamada para 200K 
+ 100 e assim por diante. Esse problema é conhecido como 
problema da realocação. 

Uma possível solução é realmente modificar as instru¬ 
ções enquanto 0 programa é carregado na memória. O pro¬ 
grama carregado na partição 1 tem 100K adicionado a cada 
endereço, 0 programa carregado na partição 2 tem 200K 
adicionado aos endereços e assim por diante. Para realizar 
uma realocação como essa durante 0 carregamento, 0 
linkeditor deve incluir no programa binário uma lista ou 
um mapa de bits, informando quais palavras do programa 
são endereços a serem realocados e quais são códigos de 
instruções, constantes ou outros itens que não devem ser 
realocados. O OS/MFT funcionava dessa maneira. Alguns 
microcomputadores também trabalham assim. 

A realocação durante 0 carregamento não resolve 0 pro¬ 
blema da proteção. Um programa malicioso sempre pode 
construir uma nova instrução e saltar para ela. Como os 
programas nesse sistema utilizam endereços absolutos de 
memória em vez de endereços relativos a um registrador, 
não há como impedir que um programa crie uma instru¬ 
ção que lê ou grava qualquer palavra na memória. Em 
sistemas multi usuários, é indesejável deixar um processo 
ler ou gravar memória pertencente a outros usuários. 

A solução que a IBM escolheu para proteger os 360 foi 
dividir a memória em blocos de 2KB e atribuir um código 
de proteção de 4 bits a cada bloco. O PSW continha uma 
chave de 4 bits. O hardware do 360 interrompia qualquer 
tentativa, por parte de um processo em execução, de aces¬ 
sar memória cujo código de proteção diferia da chave PSW. 
Uma vez que somente o sistema operacional podia alterar 
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os códigos e a chave de proteção, os processos de usuário 
eram impedidos de interferir um no outro e no próprio sis¬ 
tema operacional. 

Uma solução alternativa para ambos os problemas, re- 
alocação e proteção, é equipar a máquina com dois regis¬ 
tradores especiais de hardware, chamados registrador de 
base e registrador de limite. Quando um processo é agen¬ 
dado, o registrador de base é carregado com o endereço do 
início de sua partição, e o registrador de limite é carregado 
com o comprimento de sua partição. Todo endereço de 
memória gerado tem o registrador de base automaticamen¬ 
te adicionado a ele próprio antes de ser enviado para me¬ 
mória. Assim, se o registrador de base for 100K, uma ins¬ 
trução CALL 100 efetivamente transforma-se em uma ins¬ 
trução CALL 100K + 100, sem que a instrução em si seja 
modificada. Os endereços também são verificados em rela¬ 
ção ao registrador de limite para certificar-se de que eles 
não tentarão endereçar memória fora da partição atual. O 
hardware protege os registradores de base e de limite para 
impedir que os programas de usuário os modifiquem. 

O CDC 6600 — o primeiro supercomputador do mun¬ 
do — utilizava esse esquema. A CPU Intel 8088 utilizada 
no IBM PC original empregava uma versão mais fraca des¬ 
se esquema — os registradores de base, mas não os regis¬ 
tradores de limite. Desde os 286, um esquema melhor foi 
adotado. 


4.2 TROCA 

Com um sistema de lotes, organizar a memória em 
partições fixas é simples e efetivo. Cada job é carregado em 
uma partição quando chega no começo da fila e permane¬ 
ce na memória até que termine. Contanto que jobs sufici¬ 
entes possam ser mantidos na memória para manter a CPU 


ocupada todo o tempo, não há nenhuma razão para utili¬ 
zar qualquer coisa mais complicada. 

Com sistemas de compartilhamento de tempo ou com¬ 
putadores gráficos pessoais, a situação é diferente. As ve¬ 
zes, não há memória principal suficiente para armazenar 
todos os processos atualmente ativos, então, os processos 
em excesso são mantidos no disco e trazidos de lá para exe¬ 
cução dinamicamente. 

Duas abordagens gerais para o gerenciamento de me¬ 
mória podem ser utilizadas, dependendo (em parte) do 
hardware disponível. A estratégia mais simples, chamada 
troca, consiste em trazer cada processo inteiro, executá-lo 
temporariamente e, então, devolvê-lo ao disco. A outra es¬ 
tratégia, chamada memória virtual, permite que os pro¬ 
gramas executem mesmo quando estão apenas parcialmen¬ 
te na memória principal. A seguir, estudaremos o processo 
de troca; na Seção 4-3, examinaremos a memória virtual. 

A operação de um sistema de troca é ilustrada na Figu¬ 
ra 4-3. Inicialmente somente um processo está na memó¬ 
ria. Então, os processos B e C são criados ou recuperados 
do disco. Na Figura 4-3(d), A terminou ou é enviado para o 
disco. Então, D entra, e B sai. Por fim, E entra. 

A principal diferença entre as partições fixas da Figura 
4-2 e as partições variáveis da Figura 4-3 é que o número, 
a posição e o tamanho das partições variam dinamicamente 
na última, enquanto os processos entram e saem, ao passo 
que são fixos na primeira. A flexibilidade de não se prender 
a um número fixo de partições que podem ser ou muito 
grandes ou muito pequenas otimiza a utilização da me¬ 
mória, mas também complica a tarefa de alocar e desalo- 
car a memória, assim como a monitoração da memória 
utilizada. 

Quando a troca cria múltiplas lacunas na memória, é 
possível juntar todas elas em um grande espaço, movendo 
todos os processos para baixo o máximo possível. Essa téc- 
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Figura 4-3 As alterações de alocação de memória enquanto os processos entram e saem da memória. As regiões sombreadas 
correspondem à memória não-utilizada. 
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nica é conhecida como compactação de memória. Nor¬ 
malmente ela não é feita porque exige muito tempo da 
CPU. Por exemplo, uma máquina com 32MB que pode co¬ 
piar 16 bytes por microssegundo, leva 2 s para compactar 
toda a memória. 

Um ponto que merece ser considerado é quanta me¬ 
mória deve ser alocada para um processo quando ele é cri¬ 
ado ou é recuperado do disco. Se processos são criados com 
um tamanho fixo que nunca muda, então, a alocação é 
simples: aloca-se exatamente o que é requerido, nem mais 
nem menos. 

Se, porém, os segmentos de dados dos processos podem 
crescer, por exemplo, alocando memória dinamicamente 
a partir de um heap, como em muitas linguagens de pro¬ 
gramação, ocorre um problema sempre que um processo 
tenta crescer. Se existe uma lacuna adjacente ao processo, 
ela pode ser alocada e oferecida ao processo. Por outro lado, 
se o processo é adjacente a outro processo, o processo em 
crescimento terá de ser movido para uma lacuna de me¬ 
mória suficientemente grande para ele ou um ou mais pro¬ 
cessos terão de ser enviados para o disco para criar uma 
lacuna suficientemente grande. Se um processo não pode 
crescer na memória, e a área de troca no disco está cheia, o 
processo deverá esperar ou ser eliminado. 

Se é esperado que a maioria dos processos crescerá ao 
executar, provavelmente é uma boa idéia alocar uma pe¬ 
quena memória extra sempre que se fizer a troca ou mo¬ 
ver-se um processo, reduzindo o overhead associado com 
mover ou com trocar processos que não cabem mais na 
memória alocada para eles. Entretanto, ao enviar proces¬ 
sos para o disco, só a memória realmente em uso deve ser 


enviada; é um desperdício enviar a memória extra tam¬ 
bém. Na Figura 4-4(a) vemos uma configuração de me¬ 
mória em que o espaço para crescimento foi alocado para 
dois processos. 

Se os processos têm dois segmentos que podem crescer, 
por exemplo, o segmento de dados sendo utilizado como 
um heap para variáveis que são dinamicamente alocadas 
e liberadas e um segmento de pilha para as variáveis locais 
normais e para os endereços de retorno, um arranjo alter¬ 
nativo sugere o que é mostrado na Figura 4-4(b). Nessa 
figura, vemos que cada processo ilustrado tem uma pilha na 
parte superior de sua memória alocada que está crescendo 
para baixo e um segmento de dados imediatamente após o 
texto do programa que está crescendo para cima. A memó¬ 
ria entre eles pode ser utilizada por qualquer um dos seg¬ 
mentos. Se ele precisar de mais, ou o processo precisará ser 
movido para uma lacuna com espaço suficiente, fazendo 
troca da memória com disco até que uma lacuna seja sufi¬ 
cientemente grande possa ser criada, ou será eliminado. 

4.2.1 Gerenciamento de Memória com 
Mapas de Bits 

Quando a memória é atribuída dinamicamente, o sis¬ 
tema operacional deve gerenciá-la. Em termos gerais, há 
duas maneiras de monitorar o uso da memória: mapas de 
bits e listas livres. Nesta e na próxima seção, veremos esses 
dois métodos. 

Com um mapa de bits, a memória é dividida em uni¬ 
dades de alocação, talvez tão pequenas quanto algumas 
palavras e talvez tão grandes quanto vários kilobytes. Cor- 
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(b) em 18 (c) 


Figura 4-5 (a) Uma parte da memória com cinco processos e três lacunas. Os traços menores mostram as unidades de alocação da 

memória. As regiões sombreadas (0 no mapa de bits) estão livres, (b) O mapa de bits correspondente. (C) As mesmas informações como 
uma lista. 


respondendo a cada unidade de alocação há um bit no 
mapa de bits, que é 0 se a unidade está livre, e 1 se estiver 
ocupada (ou vice-versa). A Figura 4-5 mostra parte da 
memória e o mapa de bits correspondente. 

O tamanho da unidade de alocação é uma importante 
questão de projeto. Quanto menor a unidade de alocação, 
maior o mapa de bits. Entretanto, mesmo com uma uni¬ 
dade de alocação tão pequena quanto 4 bytes, 32 bits de 
memória exigirão somente 1 bit do mapa. Uma memória 
de 32n bits utilizará n bits de mapa, portanto o mapa de 
bits ocupará apenas 1/33 da memória. Se a unidade de alo¬ 
cação escolhida for grande, o mapa de bits será menor, mas 
uma quantia apreciável de memória pode ser desperdiça¬ 
da na última unidade se o tamanho do processo não for 
um múltiplo exato da unidade de alocação. 

Um mapa de bits oferece uma maneira simples de mo¬ 
nitorar palavras de memória em uma quantidade fixa de 
memória porque o tamanho do mapa de bits depende so¬ 
mente do tamanho da memória e do tamanho da unidade 
de alocação. 0 problema principal com isso é que quando 
se decide trazer um processo de k unidades para a memó¬ 
ria, o gerenciador de memória deve pesquisar no mapa de 
bits para encontrar uma lacuna de k bits 0 consecutivos no 
mapa. Localizar em um mapa de bits uma lacuna de um 
comprimento dado é uma operação lenta (porque a lacu¬ 
na pode escarranchar-se na faixa de palavras no mapa); 
ste é um argumento contra os mapas de bits. 

4.2.2 Gerenciamento de Memória com 
Listas Encadeadas 

Outra maneira de monitorar a memória é manter uma 
lista encadeada dos segmentos de memória alocados e li¬ 
vres, onde um segmento é um processo ou uma lacuna 
entre dois processos. A memória da Figura 4-5 (a) é repre¬ 
sentada na Figura 4-5(c) como uma lista encadeada de 


segmentos. Cada entrada na lista especifica uma lacuna 
(H) ou processo (P), o endereço em que inicia, o compri¬ 
mento e um ponteiro para a próxima entrada. 

Nesse exemplo, a lista de segmentos está classificada 
por endereço. Classificar dessa maneira tem a vantagem 
de que quando um processo termina ou está sendo enviado 
para disco, atualizar a lista é simples e direto. Um processo 
que termina normalmente tem dois vizinhos (exceto quan¬ 
do está na parte superior da memória). Esses podem ser 
tanto processos como lacunas, o que leva às quatro combi¬ 
nações da Figura 4-6. Na Figura 4-6(a), a atualização da 
lista exige substituir um P por um H. Na Figura 4-6(b) e 
na Figura 4-6(c), duas entradas são fundidas em uma, e a 
lista torna-se uma entrada mais curta. Na Figura 4-6(d), 
três entradas são fundidas, e dois itens são removidos da 
lista. Uma vez que a entrada na tabela de processos refe¬ 
rente ao processo que está terminado normalmente apon¬ 
tará para a entrada de lista do próprio processo, pode ser 
mais conveniente ter a lista como uma lista duplamente 
encadeada, em vez de uma lista simplesmente encadeada, 
como a da Figura 4-5(c) Essa estrutura torna mais 
fácil localizar a entrada anterior e ver se uma fusão é pos¬ 
sível. 

Quando os processos e as lacunas são mantidos em uma 
lista classificada por endereço, vários algoritmos podem ser 
utilizados para alocar memória para um processo recente¬ 
mente criado ou trocado para a memória. Supomos que o 
gerenciador de memória conhece a quantidade de memó¬ 
ria a alocar. 0 algoritmo mais simples é chamado algorit¬ 
mo do primeiro ajuste. O gerenciador de memória varre 
toda a lista de segmentos ate' localizar uma lacuna que 
seja suficientemente grande. A lacuna, então, é dividida 
em dois pedaços, um para o processo e um para a memó¬ 
ria não-utilizada, exceto no improvável caso de um ajuste 
exato. 0 algoritmo do primeiro ajuste é rápido porque pes¬ 
quisa o mínimo possível 
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Figura 4-6 Quatro combinações de vizinho para o processo terminante Tf. 


Uma variação secundária do algoritmo do primeiro 
ajuste é o do próximo ajuste. Ele funciona da mesma 
maneira que o primeiro ajuste, exceto que monitora a po¬ 
sição em que ele está sempre que encontra urna lacuna 
adequada. Da próxima vez que é chamado para localizar 
uma lacuna, ele começa pesquisando na lista a partir do 
lugar que ele deixou da última vez, em vez de sempre a 
partir do começo, como o primeiro ajuste faz. Simulações 
feitas por Bays (1977) demonstraram que o algoritmo do 
próximo ajuste oferece um desempenho ligeiramente infe¬ 
rior ao desempenho do algoritmo do primeiro ajuste. 

Outro algoritmo bem-conhecido é o do melhor ajus¬ 
te, o qual pesquisa na lista inteira e pega a menor lacuna 
que seja adequada. Antes de dividir uma lacuna grande 
que talvez seja necessária mais tarde, o melhor ajuste ten¬ 
ta localizar uma lacuna que é próxima do tamanho real 
necessário. 

Como um exemplo do primeiro ajuste e do melhor ajus¬ 
te, considere a Figura 4-5 novamente. Se um bloco de ta¬ 
manho 2 for necessário, o primeiro ajuste alocará a lacu¬ 
na em 5, mas o melhor ajuste alocará a lacuna em 18. 

0 melhor ajuste é mais lento que o primeiro ajuste por¬ 
que deve pesquisar na lista inteira toda vez que é chama¬ 
do. Um pouco surpreendentemente, ele também resulta em 
maior desperdício de memória que o primeiro ajuste ou o 
próximo ajuste porque tende a encher a memória de lacu¬ 
nas minúsculas e inúteis. O algoritmo de primeiro ajuste 
gera lacunas maiores, em média. 

Para evitar o problema de dividir lacunas quase exatas 
entre um processo e uma lacuna minúscula pode-se pensar 
no pior ajuste, isto é, sempre pegar a maior lacuna dispo¬ 
nível, de modo que a lacuna resultante seja suficientemen¬ 
te grande para ser útil. Contudo, simulações demonstra¬ 
ram que o pior ajuste também não é uma idéia muito boa. 

Todos os quatro algoritmos podem ser acelerados man- 
tendo-se listas separadas para processos e para lacunas. As¬ 
sim, todos eles dedicam toda sua energia para localizar la¬ 
cunas, não processos. O preço inevitável a ser pago por esse 
aceleramento da alocação é a complexidade adicional e a 
queda de velocidade ao se desalocar memória, uma vez que 
um segmento liberado tem que ser removido da lista de 
processos e inserido na lista de lacunas. 

Se listas distintas são mantidas para processos e para 
lacunas, a lista de lacunas pode ser classificada por tama¬ 


nho, tornando o algoritmo do melhor ajuste mais rápido. 
Quando o algoritmo de melhor ajuste pesquisa uma lista 
de lacunas do menor para o maior, logo que ele encontra 
uma lacuna que se ajusta, ele sabe que a lacuna é a menor 
que servirá para o job, daí o melhor ajuste. Nenhuma pes¬ 
quisa adicional é requerida, como é necessário com o es¬ 
quema de lista única. Com uma lista de lacunas classifica¬ 
da por tamanho, primeiro ajuste e melhor ajuste são igual¬ 
mente rápidos, e o próximo ajuste é sem sentido. 

Quando as lacunas são mantidas em listas separadas 
dos processos, é possível uma pequena otimização. Em vez 
de ter um conjunto separado de estruturas de dados para 
manter a lista de lacunas, como é feito na Figura 4-5(c), 
as próprias lacunas podem ser utilizadas. A primeira pala¬ 
vra de cada lacuna poderia ser o tamanho da lacuna, e a 
segunda palavra um ponteiro para a entrada seguinte. Os 
nós da lista da Figura 4-5(c), que requerem três palavras e 
um bit (P/H), não são mais necessários. 

Ainda um outro algoritmo de alocação é o ajuste rá¬ 
pido, que mantém listas separadas para alguns dos tama¬ 
nhos exigidos mais comuns. Por exemplo, você poderia ter 
uma tabela com n entradas, em que a primeira entrada é 
um ponteiro para a cabeça de uma lista de lacunas de 4K, 
a segunda entrada é um ponteiro para uma lista de lacu¬ 
nas de 8K, a terceira entrada um ponteiro para lacunas de 
12Ke assim por diante. As lacunas de, digamos, 21K, pode¬ 
riam ser colocadas na lista de 20K ou em uma lista especi¬ 
al de lacunas de tamanhos variáveis. Com ajuste rápido, 
localizar uma lacuna do tamanho exigido é extremamen¬ 
te rápido, mas tem a mesma desvantagem que todos os es¬ 
quemas que classificam por tamanho de lacuna, a saber, 
quando um processo termina ou está sendo enviado para 
disco, pesquisar seus vizinhos para ver se uma mescla é 
possível é caro. Se a mesclagem não for feita, a memória 
rapidamente será fragmentada em um grande número de 
pequenas lacunas em que nenhum processo ajusta-se. 

4.3 MEMÓRIA VIRTUAL 

Há muitos anos as pessoas defrontaram-se pela primei¬ 
ra vez com o problema dos programas que eram muito 
grandes para ajustar-se na memória disponível. A solução 
normalmente adotada era dividir o programa em pedaços, 
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chamados overlays. 0 overlay 0 começava executando 
primeiro. Quando pronto, chamava outro overlay. Alguns 
sistemas de overlay eram altamente complexos, permitin¬ 
do múltiplos overlays na memória simultaneamente. Os 
overlays eram mantidos em disco e eram levados para den¬ 
tro e para fora da memória pelo sistema operacional, di¬ 
namicamente, conforme necessário. 

Embora o trabalho real de comutação de overlays fosse 
feito pelo sistema, o trabalho de dividir o programa em 
pedaços tinha de ser feito pelo programador. Dividir pro¬ 
gramas grandes em pedaços pequenos e modulares exigia 
tempo e paciência. Não demorou muito para alguém pen¬ 
sar em uma maneira de atribuir todo o trabalho ao com¬ 
putador. 

0 método inventado (Fotheringham, 1961) veio a ser 
conhecido como memória virtual. A idéia básica por trás 
da memória virtual é que o tamanho combinado do pro¬ 
grama, dos dados e da pilha pode exceder a quantidade de 
memória física disponível para ele. O sistema operacional 
mantém essas partes do programa atualmente em uso na 
memória principal e o restante em disco. Por exemplo, um 
programa de 16 M pode executar em uma máquina de 4 
M, escolhendo cuidadosamente quais 4 M manter na 
memória a cada instante, com pedaços do programa sen¬ 
do trocados entre o disco e a memória, conforme necessá¬ 
rio. 

A memória virtual também pode trabalhar em um sis¬ 
tema de multiprogramação, com pedaços de muitos pro¬ 
gramas na memória simultaneamente. Enquanto um pro¬ 
grama está esperando parte dele próprio ser trazida para a 
memória, ele fica esperando a E/S e não pode executar; 
então, a CPU pode ser dada a outro processo, assim como 
em qualquer outro sistema de multiprogramação. 

4.3.1 Paginação 

Muitos sistemas de memória virtual utilizam uma téc¬ 
nica chamada paginação, que agora descreveremos. Em 
qualquer computador, existe um conjunto de endereços de 


memória que os programas podem produzir. Quando um 
programa utiliza uma instrução como 

MOVE REG, 1000 

ele está copiando o conteúdo do endereço de memória 1000 
para REG (ou vice-versa, dependendo do computador). 0s 
endereços podem ser gerados utilizando indexação, regis¬ 
tradores de base, registradores de segmento e outras ma¬ 
neiras. 

Esses endereços gerados por programa são chamados 
endereços virtuais e formam o espaço de endereço vir¬ 
tual; em computadores sem memória virtual, o endereço 
virtual é colocado diretamente no barramento da memó¬ 
ria e faz com que a palavra física de memória com o mes¬ 
mo endereço seja lida ou gravada. Quando é utilizada me¬ 
mória virtual, os endereços virtuais não vão diretamente 
para o barramento de memória. Em vez disso, eles vão para 
uma Unidade de Gerenciamento de Memória (Memory 
Management Unit — MMU), um chip ou uma coleção 
de chips que mapeia os endereços virtuais para os endere¬ 
ços físicos de memória comõ ilustrado na Figura 4-7. 

Um exemplo muito simples de como esse mapeamento 
funciona é mostrado na Figura 4-8, no qual, temos um 
computador que pode gerar endereços de 16 bits, de 0 a 
64K. Esses são os endereços virtuais. Esse computador, en¬ 
tretanto, tem somente 32K de memória física; então, em¬ 
bora programas de 64K possam ser escritos, eles não po¬ 
dem ser carregados na memória em sua totalidade e exe¬ 
cutados. Entretanto, uma cópia completa de uma imagem 
de núcleo do programa, até 64K, deve estar presente no dis¬ 
co, de modo que pedaços possam ser trazidos conforme 
necessário. 

O espaço de endereço virtual é dividido em unidades 
chamadas páginas. As unidades correspondentes na me¬ 
mória física são chamadas molduras de página. As pági¬ 
nas e as molduras de página têm sempre exatamente o 
mesmo tamanho. Nesse exemplo, elas têm 4K, mas tama¬ 
nhos de página de 512 bytes a 64K são comumente utiliza¬ 
dos nos sistemas existentes. Com 64K de espaço de endere- 
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Figura 4-7 A posição e a função da MMU. 
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Figura 4-8 A relação entre endereços virtuais e endereços físicos de memória é dada pela tabela de páginas. 


ço virtual e 32K de memória física, temos 1 6 páginas virtu¬ 
ais e 8 molduras de página. As transferências entre memó¬ 
ria e disco são sempre em unidades de uma página. 

Quando o programa tenta acessar o endereço 0, por 
exemplo, utilizando a instrução 

MOVE REG.O 

o endereço virtual 0 é enviado para a MMU. A MMLJ vê que 
esse endereço virtual cai na página 0 (0 a 4095), que, de 
acordo com seu mapeamento, é a moldura de página 2 
(8192 a 12287). Assim, transforma o endereço para 8192 e 
coloca o endereço 8192 no barramento. A placa de memó¬ 
ria não sabe absolutamente nada sobre a MMU e somente 
vê uma solicitação para ler ou para gravar o endereço 8192, 
que ela honra. Assim, a MMU efetivamente mapeou todos 
os endereços virtuais entre 0 e 4095 para os endereços físi¬ 
cos 8190 a 12287. 

De maneira semelhante, urna instrução 
MOVE REG.8192 
e' efetivamente transformada em 
MOVE REG,24576 

porque endereço virtual 8192 está na página virtual 2 e 
essa página e' mapeada para a moldura de página física 6 
(endereços físicos 24576 até 28671). Como um terceiro 
exemplo, o endereço virtual 20500 está a 20 bytes do início 
da página virtual 5 (endereços virtuais 20480 a 24575) e é 
mapeado sobre endereço físico 12288 + 20 = 12308. 

Por si mesmo, essa capacidade de mapear as 16 pági¬ 
nas virtuais para qualquer um das 8 molduras de página, 


configurando o mapa da MMU apropriadamente não re¬ 
solve o problema de que o espaço de endereço virtual é maior 
que a memória física. Uma vez que fisicamente temos ape¬ 
nas 8 molduras de página, somente 8 das páginas virtuais 
na Figura 4-8 são mapeadas na memória física. Os outros, 
mostrados como um X na figura, não são mapeados. No 
hardware real, um bit presente/ausente em cada entrada 
monitora se a página é mapeada ou não. 

0 que acontece se o programa tenta utilizar uma pági¬ 
na não-mapeada, por exemplo, utilizando a instrução 

MOVE REG,32780 

que é o byte 12 dentro da página virtual 8 (iniciando em 
32768)? A MMU nota que a página não está mapeada (in¬ 
dicada por um xis na figura) e gera uma interrupção, pas¬ 
sando a CPU para o sistema operacional. Tal interrupção é 
chamada falha de página. O sistema operacional selecio¬ 
na uma moldura de página pouco utilizada e grava o seu 
conteúdo de volta no disco. Então, ele busca a página que 
acabou de ser referenciada e carrega-a na moldura de pá¬ 
gina que acabou de ser liberada, altera o mapa e reinicia a 
instrução interrompida. 

Por exemplo, se o sistema operacional decidisse liberar 
a moldura de página 1, ele carregaria a página virtual 8 
no endereço físico 4K e faria duas alterações no mapa da 
MMU. Primeiro, marcaria a entrada da página virtual 1 
como não-mapeada, para impedir qualquer futuro acesso 
a endereços virtuais entre 4K e 8K. Então, substituiria o X 
na entrada de página virtual 8 por um 1, de modo que 
quando a instrução interrompida é reexecutada, ela ma- 
peará o endereço virtual 32780 para o endereço físico 4108. 
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Agora vamos olhar dentro da MMU para ver como ela 
funciona e por que escolhemos utilizar um tamanho de 
página que é uma potência de 2. Na Figura 4-9, vemos um 
exemplo de um endereço virtual, 8196 (0010000000000100 
em binário), sendo mapeado utilizando o mapa de MMU 
da Figura 4-8. O endereço virtual de 16 bits que chega é 
dividido em um número de página de 4 bits e um desloca¬ 
mento de 12 bits. Com 4 bits para o número de página, 
podemos representar 16 páginas; e com 12 bits para o des¬ 
locamento, podemos endereçar todos os 4096 bytes dentro 
de uma página. 

O número de página é utilizado como um índice na 
tabela de páginas, que fornece o número da moldura de 
página correspondente a essa página virtual. Se o b\\.pre¬ 
sente/ausente for 0, uma interrupção é gerada, passando a 
CPU para o sistema operacional. Se o bit for 1, o número 
da moldura de página localizado na tabela de páginas será 
copiado para os 3 bits de ordem superior do registrador de 
saída, junto com o deslocamento de 12 bits, que e' copiado 
sem modificações do endereço virtual dado. Juntos, eles 
formam um endereço físico de 15 bits. O registrador de sa¬ 
ída, então, é colocado sobre o barramento de memória como 
o endereço físico de memória. 


4.3.2 Tabelas de Página 

Na teoria, o mapeamento de endereços virtuais para 
endereços físicos é como acabamos de descrever. O endere¬ 
ço virtual é dividido em um número de página virtual (bits 
de ordem superior) e um deslocamento (bits de ordem in¬ 
ferior) . O número de página virtual é utilizado como um 
índice na tabela de páginas para localizar a entrada para 
essa página virtual. A partir da entrada da tabela de pági¬ 
nas, o número da moldura de página (se há alguma) é 
localizado. O número da moldura de página é anexado à 
extremidade de ordem superior do deslocamento, substitu¬ 
indo o número de página virtual, para formar um endere¬ 
ço físico que pode ser enviado para a memória. 

O propósito da tabela de páginas é mapear páginas vir¬ 
tuais em molduras de página. Matematicamente falando, 
a tabela de páginas é uma função, com o número de pági¬ 
na virtual como argumento, e o número da moldura física 
como resultado. Utilizando o resultado dessa função, o cam¬ 
po de página virtual em um endereço virtual pode ser subs¬ 
tituído por um campo de moldura de página, formando, 
assim, um endereço físico de memória. 
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Figura 4-9 A operação interna da MMU com 16 páginas 4K. 
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Apesar dessa descrição simples, duas questões impor¬ 
tantes devem ser encaradas: 

1. A tabela de páginas pode ser extremamente grande. 

2. O mapeamento deve ser rápido. 

O primeiro ponto é consequência do fato de que computa¬ 
dores modernos utilizam endereços virtuais de pelo menos 
32 bits. Com, digamos, um tamanho de página de 4K, um 
espaço de endereçamento de 32 bits de endereço tem 1 mi¬ 
lhão de páginas, e um espaço de endereçamento de 64 bits 
tem mais do que você pode contemplar. Com 1 milhão de 
páginas, no espaço de endereçamento virtual, a tabela de 
páginas deve ter 1 milhão de entradas. E lembre-se de que 
cada processo necessita da própria tabela de páginas. 

O segundo ponto é uma conseqüência do fato de que o 
mapeamento de virtual para físico deve ser feito em cada 
referência da memória. Uma instrução típica tem uma 
palavra de instrução e freqüentemente um operando de 
memória também. Portanto, é necessário fazer 1, 2 ou, às 
vezes, mais referências da tabela de páginas por instrução. 
Se uma instrução toma, digamos, 10ns, a pesquisa na ta¬ 
bela de páginas deve ser feita em poucos nanossegundos 
para que não se torne um gargalo importante. 

A necessidade de um mapeamento de páginas rápido e 
grande é uma limitação significativa na maneira como os 
computadores são construídos. Embora o problema mais 
sério seja com máquinas topo de linha, é também uma 
questão na extremidade baixa, onde custo e preço/desem¬ 
penho são críticos. Nesta seção e nas seguintes, veremos o 
projeto da tabela de páginas detalhadamente e mostrare¬ 
mos algumas soluções de hardware que foram utilizadas 
em computadores reais. 

O projeto mais simples (pelo menos conceitualmente) 
é ter uma única tabela de páginas consistindo em uma 
matriz de rápidos registradores de hardware, com uma en¬ 
trada para cada página virtual, indexada pelo número de 
página virtual. Quando um processo é iniciado, o sistema 
operacional carrega os registradores com a tabela de pági¬ 
nas do processo, tomada de uma cópia mantida na memó¬ 
ria principal. Durante a execução do processo, referências 
de memória não são mais requeridas para a tabela de pá¬ 
gina. As vantagens desse método são que ele é simples e 
direto e não exige nenhuma referência de memória du¬ 
rante o mapeamento. Uma desvantagem é que é potenci¬ 
almente caro (se a tabela de páginas é grande). Ter de car¬ 
regar a tabela de páginas em cada comutação de contexto 
também pode prejudicar o desempenho. 

No outro extremo, a tabela de páginas pode estar intei¬ 
ramente na memória principal. Uido o que o hardware pre¬ 
cisa, então, é de um único registrador que aponta para o 
início da tabela de páginas. Esse projeto permite que o mapa 
de memória seja alterado em uma comutação de contexto, 
recarregando um registrador. Naturalmente, tem a desvan¬ 
tagem de exigir que uma ou mais referências de memória 
leiam entradas da tabela de páginas durante a execução de 
cada instrução. Por essa razão, essa abordagem raramente 
é utilizada em sua forma mais pura, mas a seguir estuda¬ 


remos algumas variações que têm desempenho muito me¬ 
lhor. 

Tabelas de Páginas Multinível 

Para evitar o problema de ter enormes tabelas de pági¬ 
na na memória todo o tempo, muitos computadores utili¬ 
zam uma tabela de páginas multinível. Um exemplo sim¬ 
ples é mostrado na Figura 4-10. Na Figura 4-10(a), temos 
um endereço virtual de 32 bits que é particionado em um 
campo PT1 de 10 bits, um campo PT2 de 10 bits e um cam¬ 
po de deslocamento de 12 bits. Uma vez que os desloca¬ 
mentos são de 12 bits, as páginas são de 4K e há um total 
de 2 20 deles. 

O segredo para o método de tabela de páginas multiní¬ 
vel é evitar manter todas as tabelas de página na memória 
todo o tempo. Em particular, aquelas que não são necessá¬ 
rias não devem ser mantidas. Suponha, por exemplo, que 
um processo necessite de 12 megabytes, os 4 megabytes da 
parte inferior da memória para texto do programa, os pró¬ 
ximos 4 megabytes para dados e os 4 megabytes da parte 
superior para a pilha. Entre a porção acima dos dados e a 
porção baixa das pilha há uma lacuna gigantesca que não 
é utilizada. 

Na Figura 4-10(b) vemos como a tabela de páginas de 
dois níveis funciona nesse exemplo. Na esquerda, temos a 
tabela de páginas de primeiro nível, com 1024 entradas, 
correspondente ao campo de 10 bits/TA. Quando um en¬ 
dereço virtual é apresentado para a MMU, ela primeiro ex¬ 
trai o campo PT1 e utiliza esse valor como um índice na 
tabela de páginas de primeiro nível. Cada uma dessas 1024 
entradas representa 4 M porque o espaço de endereçamen¬ 
to virtual de 4 gigabytes inteiro (i. e., de 32 bits) foi dividi¬ 
do em pedaços de 1024 bytes. 

A entrada localizada na pesquisa na tabela de páginas 
de primeiro nível fornece o endereço ou o número da mol¬ 
dura de página de uma tabela de páginas de segundo ní¬ 
vel. A entrada 0 da tabela de páginas de primeiro nível apon¬ 
ta para a tabela de páginas do texto do programa, a entra¬ 
da 1 aponta para a tabela de páginas dos dados e a entrada 
1023 aponta para a tabela de páginas da pilha. As outras 
entradas (sombreadas) não são utilizadas. O campo PT2 é 
agora utilizado como um índice na tabela de páginas de 
segundo nível selecionada para localizar o número da 
moldura de página para a página em si. 

Como um exemplo, considere o endereço virual de 32 
bits 0x00403004 (4.206.596 em decimal), que está 12.292 
bytes nos dados. Esse endereço corresponde a PT1 = 1,PT2 
= 3 e deslocamento = 4. A MMU primeiro utiliza PT1 para 
indexar na tabela de páginas de primeiro nível e para obter 
a entrada 1, que corresponde aos endereços de 4 M a 8 M. 
Então, ela utiliza PT2 para indexar na tabela de páginas 
de segundo nível recém-localizada e extrair a entrada 3, 
que corresponde aos endereços de 12288 a 16383 dentro de 
seu bloco de 4 M (i. e., endereços absolutos de 4.206.592 
até 4.210.687). Essa entrada contém o número da moldu¬ 
ra de página da página onde se encontra o endereço virtu- 
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Figura 4-10 (a) Um endereço de 32 bits com dois campos de tabela de páginas, (b) Tabelas de páginas de dois níveis. 


al 0x00403004. Se essa página não estiver na memória, o 
bit presente/ausente na entrada da tabela de páginas será 
zero, causando uma falha de página. Se a página estiver na 
memória, o número da moldura de página tomado da ta¬ 
bela de páginas de segundo nível é combinado com o deslo¬ 
camento (4) para construir um endereço físico. Esse ende¬ 
reço é colocado no barramento e enviado para a memória. 

A coisa interessante a observar sobre a Figura 4-10 é 
que embora o espaço de endereçamento contenha mais de 
um milhão de páginas, somente quatro tabelas de página 
realmente são exigidas: a tabela de primeiro nível e as de 
segundo nível para 0 a 4M, 4 M a 8 M e para os 4 M superi¬ 
ores. Os bits presente/ausente em 1021 entradas da tabela 
de páginas de primeiro nível são configurados como 0, for¬ 
çando uma falha de página se elas forem acessadas. Se isso 


ocorrer, o sistema operacional receberá que o processo está 
tentando referenciar memória que não lhe foi destinada e 
tomará ação apropriada, como enviar a ele um sinal ou 
eliminá-lo. Nesse exemplo, escolhemos números redondos 
para os vários tamanhos e selecionamos PT1 igual a PT2, 
mas, na prática, outros valores também são possíveis, na¬ 
turalmente. 

O sistema de tabela de páginas de dois níveis da Figura 
4-10 pode ser expandido para três, para quatro ou para mais 
níveis. Níveis adicionais dão mais flexibilidade, mas é du¬ 
vidoso que a complexidade adicional valha a pena além de 
três níveis. 

Agora vamos deixar a estrutura das tabelas de páginas 
no geral e ir para os detalhes de uma única entrada de 
tabela de páginas. O arranjo exato de uma entrada é alta- 
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mente dependente de máquina, mas os tipos de informa¬ 
ções presentes são grosseiramente os mesmos de máquina 
para máquina. Na Figura 4-11, damos uma entrada de ta¬ 
bela de página de exemplo. O tamanho varia de computa¬ 
dor para computador, mas 32 bits é um tamanho comum. 
O campo mais importante é o número da moldura de pá¬ 
gina. Afinal de contas, o objetivo do mapeamento de pági¬ 
na é localizar esse valor. Perto dele, temos o bit presente/ 
ausente. Se esse bit for 1, a entrada é válida e pode ser uti¬ 
lizada. Se for 0, a página virtual a que a entrada pertence 
não está atualmente na memória. Acessar uma entrada da 
tabela de páginas com esse bit configurado como zero causa 
uma falha de página. 

Os b'\\sproteção informam que tipos de acesso são per¬ 
mitidos. Na forma simples, esse campo conte'm 1 bit, com 
0 para leitura/gravação e 1 para leitura somente. Um ar¬ 
ranjo mais sofisticado é ter 3 bits, cada um para habilitar 
leitura, gravação e execução da página. 

Os bits modificada e refei-enciada monitoram o uso da 
página. Quando se escreve em uma página, o hardware 
automaticamente liga o bit modificada. Esse bit é valioso 
quando o sistema operacional decide reivindicar uma mol¬ 
dura de página. Se a página nela foi modificada (i. e., está 
“suja”), ela deve ser gravada de volta no disco. Se ela não 
foi modificada (i. e., está “limpa”), ela pode ser simples¬ 
mente abandonada, uma vez que a cópia no disco ainda é 
válida. O bit às vezes é chamado de bit sujo, uma vez que 
reflete o estado da página. 

O bit referenciada é ligado sempre que uma página é 
referenciada, seja para ler ou para gravar. Seu objetivo é 
ajudar o sistema operacional a escolher uma página a ex¬ 
pulsar quando uma falha de página ocorre. As páginas que 
não estão sendo utilizadas são melhores candidatas que as 
páginas que estão, e esse bit desempenha um papel impor¬ 
tante em vários dos algoritmo de substituição de página 
que veremos mais adiante neste capítulo. 

Por fim, o último bit permite que o cache seja desativa¬ 
do para a página. Esse recurso é importante para páginas 
que são mapeadas em registradores de dispositivo em vez 
da memória. Se o sistema operacional está preso em um 
laço estrito, esperando algum dispositivo de E/S responder 
a um comando que acaba de dar, é essencial que o har¬ 
dware continue buscando a palavra do dispositivo e não 
utilize uma cópia de cache antiga. Com esse bit, a opera¬ 


ção de cache pode ser desligada. As máquinas que têm um 
espaço separado de E/S e não utilizam E/S mapeada em 
memória não necessitam desse bit. 

Note que o endereço de disco utilizado para armazenar 
a página quando não está na memória não é parte da ta¬ 
bela de páginas. A razão é simples. A tabela de página ar¬ 
mazena somente as informações de que o hardware preci¬ 
sa para traduzir um endereço virtual em um endereço físi¬ 
co. As informações que o sistema operacional necessita para 
tratar falhas de página são mantidas em tabelas de softwa¬ 
re dentro do sistema operacional. 

4.3.3 TLBs — Translation Lookaside 
Buffers 

Na maioria dos esquemas de paginação, as tabelas de 
página são mantidas na memória, devido ao seu tamanho 
grande. Potencialmente, esse projeto tem um enorme im¬ 
pacto sobre o desempenho. Considere, por exemplo, uma 
instrução que copia um registrador para outro. Na ausên¬ 
cia de paginação, essa instrução faz somente uma referên¬ 
cia à memória, para buscar a instrução. Com a paginação, 
referências de memória adicionais serão necessárias para 
acessar a tabela de páginas. Uma vez que a velocidade de 
execução geralmente é limitada pela taxa com que a CPU 
pode obter instruções e dados da memória, ter de fazer duas 
referências de tabela de páginas por referência de memó¬ 
ria reduz o desempenho em 2/3. Sob essas condições, nin¬ 
guém a utilizaria. 

Os projetistas de computador sabiam desse problema 
havia anos e ofereceram uma solução. Sua solução é base¬ 
ada na observação de que a maioria dos programas tende 
a fazer um grande número de referências a um pequeno 
número de páginas, e não o contrário. Assim somente uma 
pequena fração de entradas da tabela de páginas é intensa¬ 
mente lida; o restante é muito pouco utilizado. 

A solução inventada foi equipar computadores com um 
pequeno dispositivo de hardware para mapear endereços 
virtuais em endereços físicos sem passar pela tabela de pá¬ 
ginas. O dispositivo, chamado TLB (Translation Looka¬ 
side Buffer) ou, às vezes, memória associativa, é ilus¬ 
trado na Figura 4-12. Normalmente, ele está dentro da MMU 
e consiste em um pequeno número de entradas, oito nesse 
exemplo, mas raramente mais de 64. Cada entrada con- 
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Figura 4-11 Uma entrada típica de tabela de páginas. 
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tém as informações sobre uma página, em particular, o 
número de página virtual, um bit que é ligado quando a 
página é modificada, o código de proteção (permissões para 
ler/gravar/executar) e a moldura de página física em que 
a página está localizada. Esses campos têm correspondên¬ 
cia um para um com os campos na tabela de páginas. Ou¬ 
tro bit indica se a entrada é válida (i. e., está em uso) ou 
não. 

Um exemplo que pode gerar o TLB da Figura 4-12 é um 
processo em um laço que se estende pelas páginas virtuais 
19, 20 e 21, de tal modo que essas entradas de TLB têm 
códigos de proteção para ler e executar. Os dados princi¬ 
pais atualmente sendo utilizados (digamos, uma matriz 
que está sendo processada) estão nas páginas 129 e 130. A 
página 140 contém os índices utilizados nos cálculos da' 
matriz. Por fim, a pilha está nas páginas 860 e 86 1. 

Vejamos agora como o TLB funciona. Quando um en¬ 
dereço virtual é apresentado para a MMU para tradução, o 
hardware primeiro verifica se seu número de página virtu¬ 
al está presente no TLB, comparando-o com todas as en¬ 
tradas simultaneamente (i. e., em paralelo). Se uma coin¬ 
cidência válida for localizada, e o acesso não violar os bits 
de proteção, a moldura de página será tomada diretamen¬ 
te do TLB, sem passar pela tabela de páginas. Se o número 
de página virtual estiver presente no TLB, mas a instrução 
estiver tentando gravar em uma página com permissão ape¬ 
nas de leitura, uma falha de proteção será gerada, da mes¬ 
ma maneira como seria a partir da própria tabela de pági¬ 
nas. 

O caso interessante é o que acontece quando o número 
de página virtual não está no TLB. A MMU detecta a falta e 
faz uma pesquisa rotineira na tabela de páginas. Então, 
ela expulsa uma das entradas do TLB e substitui-a pela 
entrada da tabela de páginas recém-pesquisada. Assim, se 
essa página for utilizada novamente logo, a segunda vez 
resultará em um acerto em vez de uma falta. Quando uma 
entrada é purgada do TLB, o bit modificada é copiado de 
volta para a entrada da tabela de páginas na memória. Os 
outros valores já estão aí. Quando o TLB é carregado da 
tabela de páginas, todos os campos são tomados da memó¬ 
ria. 

Gerenciamento por Software do TLB 

Até agora, assumimos que cada máquina com memó¬ 
ria virtual paginada tem tabelas de páginas reconhecidas 
pelo hardware, mais um TLB. Nesse projeto, gerenciamen¬ 
to de TLB e tratamento de falhas de TLB são feitos inteira¬ 
mente pelo hardware de MMU. As interrupções para o siste¬ 
ma operacional ocorrem somente quando uma página não 
está na memória. 

No passado, essa suposição era verdadeira. Entretanto, 
algumas máquinas RISC modernas, incluindo MIPS, Alfa 
e HP PA, fazem quase todo o gerenciamento de páginas em 
software. Nessas máquinas, as entradas de TLB são explici¬ 
tamente carregadas pelo sistema operacional. Quando uma 
falta de TLB ocorre, em vez de a MMU simplesmente ir para 


a tabela de páginas localizar e buscar a referência de pági¬ 
na necessária, ela apenas gera uma falha de TLB e joga o 
problema para o sistema operacional. O sistema deve loca¬ 
lizar a página, remover uma entrada do TLB, entrar de novo 
e reiniciar a instrução que falhou. E, naturalmente, tudo 
isso deve ser feito em um punhado de instruções porque 
faltas de TLB ocorrem com muito mais freqüência que fa¬ 
lhas de paginação. 

Surpreendentemente, se o TLB for razoavelmente grande 
(digamos, 64 entradas) para reduzir a taxa de falta, o ge¬ 
renciamento por software do TLB vem a ser bastante efici¬ 
ente. O ganho principal aqui é uma MMU muito mais sim¬ 
ples, o que libera uma quantidade considerável de área no 
chip da CPU para caches e para outros recursos que podem 
melhorar o desempenho. O gerenciamento por software do 
TLB é discutido demoradamente por Uhlig e colaboradores 
(1994). 

Várias estratégias foram desenvolvidas para melhorar 
o desempenho em máquinas que fazem gerenciamento do 
TLB por software. Uma abordagem é reduzir as faltas de 
TLB e reduzir os custos de uma falta de TLB quando ocorre 
(Bala et al, 1994). Para reduzir faltas de TLB, às vezes, o 
sistema operacional pode utilizar sua intuição para desco¬ 
brir que páginas podem ser utilizadas em seguida e pré- 
carregar entradas para elas no TLB. Por exemplo, quando 
um processo de cliente faz uma RPC* para um processo de 
servidor na mesma máquina, é muito possível que o servi¬ 
dor precisará executar em breve. Sabendo disso, ao proces¬ 
sar a interrupção para fazer o RPC, o sistema também pode 
verificar onde o código do servidor, os dados e as páginas 
de pilha estão e mapeá-los antes de eles poderem causar 
falhas de TLB. 

A maneira normal de processar uma falta de TLB, em 
hardware ou em software, é ir para a tabela de páginas e 
executar as operações de indexação para localizar a pági¬ 
na referenciada. O problema ao fazer essa pesquisa em sof¬ 
tware é que as páginas que armazenam a tabela de pági¬ 
nas podem não estar no TLB, o que causará falhas adicio¬ 
nais de TLB durante o processamento. Essas falhas podem 
ser reduzidas mantendo um grande (p. ex., 4K) cache de 
software de entradas de TLB em uma posição fixa cuja pa¬ 
gina sempre é mantida no TLB. Por primeiro verificar o 
cache de software, o sistema operacional pode reduzir subs¬ 
tancialmente faltas de TLB. 

4.3.4 Tabelas de Páginas Invertidas 

Tabelas de páginas tradicionais, do tipo descrito até 
agora, exigem uma entrada por página virtual, uma vez 
que são indexadas por número de página virtual. Se o es¬ 
paço de endereçamento consiste em T > 2 bytes, com 4096 
bytes por página, então, são necessárias mais de 1 milhão 
de entradas de tabela de página. Como um mínimo, a ta- 


*N. de T. Remote Procedure Call, chamada remota de procedimento. 
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Figura 4-12 Um TLB para acelerar a paginação. 


bela de páginas deverá ter pelo menos 4 megabytes. Em 
sistemas maiores, esse tamanho é provavelmente factível. 

Entretanto, à medida que computadores de 64 bits tor- 
nam-se mais comuns, a situação muda drasticamente. Se 
o espaço de endereço é agora de 2 64 bytes com páginas de 
4K, necessitamos mais de 10 15 bytes para a tabela de pági¬ 
nas. Prender mais de 1 milhão de gigabytes somente para 
a tabela de páginas não é aceitável, não por enquanto e 
não pelas próximas de'cadas, se é que algum dia será. Por¬ 
tanto, uma solução diferente é requerida para espaços de 
endereço virtual paginados de 64 bits. 

A solução para isso é a tabela de páginas invertida. 
Nesse projeto, há uma entrada por moldura de página na 
memória real, em vez de uma entrada por página de espa¬ 
ço de endereço virtual. Por exemplo, com endereços virtu¬ 
ais de 64 bits, uma página 4K e 32MB de RAM, uma tabela 
de página invertida somente precisa de 8192 entradas. A 
entrada monitora qual (processo, página virtual) está lo¬ 
calizado na moldura de página. 

Embora as tabelas de página invertidas economizem 
quantidades significativas de espaço, pelo menos quando o 
espaço de endereço virtual é muito maior que a memória 
física, elas têm uma desvantagem séria: a tradução de vir¬ 
tual para físico torna-se muito mais difícil. Quando o pro¬ 
cesso n referencia a página virtual p, o hardware não pode 
mais localizar a página física utilizando p como um índi¬ 
ce na tabela de página. Em vez disso, ele deve pesquisar na 
tabela de página invertida inteira uma entrada ( n,p ). Além 
disso, essa pesquisa deve ser feita em cada referência de 
memória, não somente em falhas de página. Pesquisar uma 
tabela de 8K em cada referência de memória não é a ma¬ 
neira certa de tornar rápida sua máquina. 

A saída para esse dilema é utilizar o TLB. Se o TLB pode 
armazenar todas as páginas mais utilizadas, a tradução 
pode acontecer igualmente rápida como com tabelas de 
páginas comuns. Em uma falta de TLB, entretanto, a tabe¬ 
la de página invertida precisa ser pesquisada. Entretanto, 
utilizando uma tabela de hash como um índice na tabela 
de página invertida, essa pesquisa pode ser tornada razoa¬ 
velmente rápida. As tabelas de página invertidas são atual¬ 


mente utilizadas em algumas estações de trabalho IBM e 
Hewlett-Packard e vão se tornar mais comuns à medida 
que as máquinas de 64 bits difundirem-se. 

Outra abordagem para tratamento de memórias virtu¬ 
ais grandes pode ser encontrada em (Huck e Hays, 1993; 
Talluri e Colina, 1994: e Talluri et ai, 1995). 


4.4 ALGORITMOS DE SUBSTITUIÇÃO 
DE PÁGINA 

Quando ocorre uma falha de página, o sistema opera¬ 
cional precisa escolher uma página para remover da me¬ 
mória e dar lugar para a página que precisa ser carregada. 
Se a página a ser removida tiver sido modificada enquanto 
na memória, ela deve ser regravada no disco para atuali¬ 
zar a cópia em disco. Se, entretanto, a página não foi alte¬ 
rada (p. ex., uma página contém texto de programa), a 
cópia em disco já está atualizada; então, nenhuma regra- 
vação é exigida. A página a ser lida simplesmente sobres- 
creve a página sendo expulsa. 

Embora seja possível selecionar aleatoriamente uma 
página para remover em cada falha de página, o desempe¬ 
nho do sistema será muito melhor se uma página que não 
é intensamente utilizada for escolhida. Se uma página in¬ 
tensamente utilizada for removida, provavelmente ela pre¬ 
cisará ser trazida de volta em breve, o que resulta em so¬ 
brecarga extra. Muitos trabalhos foram feitos sobre o as¬ 
sunto de algoritmo de substituição de página, tanto teóri¬ 
cos como experimentais. A seguir, descreveremos alguns 
dos algoritmos mais importantes. 

4.4.1 Algoritmo de Substituição de 
Página Ótimo 

0 melhor algoritmo de substituição de página possível 
é fácil de descrever mas impossível de implementar. Acom¬ 
panhe o raciocínio. No momento em que uma falha de 
página ocorre, algum conjunto de páginas está na memó¬ 
ria. Uma dessas páginas será referenciada na instrução mais 



226 TANENBAUM & WOODHULL 


próxima (a página que contém essa instrução). Outras 
páginas podem não ser referenciadas até 10,100 ou talvez 

I. 000 instruções mais tarde. Cada página pode ser rotula¬ 
da com o número de instruções que será executado antes 
de essa página ser referenciada pela primeira vez. 

O algoritmo de página ótimo simplesmente diz que a 
página com o rótulo mais alto deve ser removida. Se uma 
página não será utilizada por 8 milhões de instruções e 
outra página não será utilizada por 6 milhões de instru¬ 
ções, remover a primeira empurra a falha de página que a 
buscará de volta para o mais tarde possível. Os computa¬ 
dores, como as pessoas, tentam adiar eventos desagradá¬ 
veis o máximo que puderem. 

O único problema com esse algoritmo é que ele não é 
realizável. No momento da falha de página, o sistema ope¬ 
racional não tem como saber quando cada uma das pági¬ 
nas será referenciada em seguida. (Vimos uma situação 
semelhante anteriormente com o algoritmo de agendamen- 
to job mais curto primeiro — como o sistema pode dizer 
qual job é mais curto?) Ademais, executando um progra¬ 
ma em um simulador e monitorando todas as referências 
de página, é possível implementar substituição de página 
ótima na segunda execução utilizando as informações de 
referência de página coletadas durante a primeira execu¬ 
ção. 

Dessa maneira é possível comparar o desempenho de 
algoritmos realizáveis com o melhor possível. Se um siste¬ 
ma operacional alcançar um desempenho de, digamos, 
somente 1% pior do que o algoritmo ótimo, o esforço gasto 
em pesquisar um melhor algoritmo resultará em uma 
melhora de 1% no máximo 

Para evitar qualquer possível confusão, deve-se deixar 
claro que esse registro de referências de página refere-se 
apenas ao programa recém-medido. O algoritmo de subs¬ 
tituição de página derivado dele é específico desse progra¬ 
ma. Embora esse método seja útil para avaliar algoritmos 
de substituição de página, ele não serve para nada em sis¬ 
temas práticos. A seguir, estudaremos algoritmos que são 
úteis em sistemas reais. 

4.4.2 Algoritmo de Substituição de 
Página Não Recentemente Utilizada 

Para permitir que o sistema operacional colecione es¬ 
tatísticas úteis sobre quais páginas estão sendo utilizadas e 
quais não estão, a maioria dos computadores com memó¬ 
ria virtual tem dois bits de status associados a cada página. 
R é configurado sempre que a página é referenciada (lei¬ 
tura ou gravação). M é configurado quando a página é 
gravada (i. e., modificada). Os bits são contidos em cada 
entrada da tabela de páginas, como mostrado na Figura 4- 

II. É importante saber que esses bits devem ser atualizados 
em cada referência de memória, então, é essencial que se¬ 
jam configurados pelo hardware. Uma vez que um bit foi 


configurado como 1, ele permanece como 1 até que o siste¬ 
ma operacional o redefina para 0 em software. 

Se o hardware não tiver esses bits, eles podem ser simu¬ 
lados da seguinte maneira. Quando um processo é inicia¬ 
do, todas as entradas da tabela de páginas são marcadas 
como não estando na memória. Logo que qualquer página 
é referenciada, ocorrerá uma falha de página. O sistema 
operacional, então, liga o bit R (em suas tabelas internas), 
altera a entrada da tabela de páginas para apontar para a 
página correta, com modo apenas para leitura, e reinicia a 
instrução. Se a página for subseqüentemente gravada, ocor¬ 
rerá outra falha de página, permitindo que o sistema ope¬ 
racional ligue o bit M e altere o modo da página para leitu¬ 
ra/escrita. 

O bits R e M podem ser utilizados para construir um 
algoritmo de paginação simples como segue. Quando um 
processo é iniciado, os dois bits de página para todas as 
suas páginas são configurados como 0 pelo sistema opera¬ 
cional. Periodicamente (p. ex., a cada interrupção do reló¬ 
gio), o bit /? é limpo, distinguindo páginas que não foram 
referenciadas recentemente das que foram. 

Quando ocorre uma falha de página, o sistema opera¬ 
cional inspeciona todas as páginas e divide-as em quatro 
categorias com base nos valores atuais de seu bits R e M: 

A classe 0: não-referenciada, não-modificada. 

A classe 1: não-referenciada, modificada. 

A classe 2: referenciada, não-modificada. 

A classe 3: referenciada, modificada. 

Embora as páginas de classe 1 pareçam impossíveis à pri¬ 
meira vista, elas ocorrem quando uma página de classe 3 
tem seu bit R limpo por uma interrupção de relógio. A in¬ 
terrupção de relógio não limpa o bit M porque essa infor¬ 
mação é necessária para saber se a página tem de ser re- 
gravada no disco ou não. 

O algoritmo NRU (Não Recentemente Utilizada) re¬ 
move uma página em execução da classe não-vazia com a 
numeração mais baixa. Implícito nesse algoritmo está o 
fato de que é melhor remover uma página modificada que 
não foi referenciada no período de um tique de relógio (em 
geral 20ms) do que uma página limpa que está em uso 
intenso. A principal atração do NRU é que é fácil de enten¬ 
der, sua implementação é eficiente e ele oferece um de¬ 
sempenho que, embora certamente não-ótimo, é frequen¬ 
temente adequado. 

4.4.3 Algoritmo de Substituição de 
Página Primeira a Entrar, Primeira a 
Sair (FIFO) 

Outro algoritmo de paginação de baixo overhead é o 
algoritmo FIFO ( First-In, First-Out). Para ilustrar como 
isso funciona, considere um supermercado que tem prate¬ 
leiras suficientes para exibir exatamente k produtos dife¬ 
rentes. Um dia, uma empresa introduz um novo alimento 
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de conveniência — um tipo de iogurte congelado e seco 
para preparo instantâneo, que pode ser reconstituído em 
um forno de microondas. 0 produto é um sucesso imedia¬ 
to, então, nosso limitado supermercado precisa livrar-se de 
um produto antigo para armazenar o novo. 

Uma possibilidade é localizar o produto que o super¬ 
mercado armazena há mais tempo (i. e., algo que come¬ 
çou a vender 120 anos atrás) e livrar-se dele com base no 
fato de que ninguém está mais interessado nele. Por sorte, 
o supermercado mantém uma lista de todos os produtos 
atualmente vendidos na ordem em que eles foram intro¬ 
duzidos. O novo entra no fim na lista; aquele que está no 
começo da lista é derrubado. 

Como um algoritmo de substituição de página, a mes¬ 
ma idéia é aplicável. O sistema operacional mantém uma 
lista de todas as páginas atualmente na memória, sendo 
que a página no topo da lista é a mais antiga, e a página 
no fim é a mais recente. Em uma falha de página, a pági¬ 
na no topo é removida e a nova página é adicionada no 
fim da lista. Quando aplicado a estoques, F1FO talvez re¬ 
mova produtos como vaselina para bigodes, mas talvez tam¬ 
bém remova farinha, sal ou manteiga. Quando aplicado a 
computadores, o mesmo problema surge. Por essa razão, 
FIFO em sua forma pura é raramente utilizado. 

4.4.4 Algoritmo de Substituição de 
Página de Segunda Chance 

Uma modificação simples do FIFO que evita o proble¬ 
ma de jogar fora uma página intensamente utilizada é ins¬ 
pecionar o bit R da página mais antiga. Se for 0, a página 
será antiga ou não-utilizada, então, ela é substituída ime¬ 
diatamente. Se o bit /? for 1, o bit será limpo, a página será 
colocada no fim da lista de páginas e seu tempo de carga é 
atualizado como se acabasse de chegar na memória. En¬ 
tão, a pesquisa continua. 

A operação desse algoritmo, chamado algoritmo de 
segunda chance, é mostrada na Figura 4-13. Na Figura 4- 
13 (a), vemos páginas/! a// mantidas em uma lista enca¬ 


deadas e classificadas pelo tempo em que chegaram à me¬ 
mória. 

Suponha que uma falha de página ocorra no tempo 
20. Apágina mais antiga éA, que chegou no tempo 0, quan¬ 
do o processo iniciou. Se o bit A de A estiver limpo, ela é 
expulsa da memória, seja sendo gravada no disco (se esti¬ 
ver suja) ou simplesmente sendo abandonada (se estiver 
limpa). Por outro lado, se o bit R estiver ligado,/! é coloca¬ 
da no fim da lista e seu “tempo de carga" é reconfigurado 
como o tempo atual (20). O bit /? também é limpo. A busca 
por uma página adequada continua com B. 

O que o algoritmo de segunda chance está fazendo é 
pesquisar uma página antiga que não foi referenciada no 
intervalo de relógio anterior. Se todas as páginas foram re¬ 
ferenciadas, o algoritmo de segunda chance degenera em 
FIFO puro. Especificamente, imagine que todas as páginas 
naFigura4-13(a) tenham seus bits/? ligados. Umporum, 
o sistema operacional move as páginas para o fim da lista, 
e limpa o bit R cada vez que anexa uma página ao fim da 
lista. Por fim, ele volta para a página/!, que agora tem seu 
bit R limpo. Nesse ponto, A é expulsa. Assim o algoritmo 
sempre termina. 

4.4.5 Algoritmo de Substituição de 
Página do Relógio 

Embora o algoritmo de segunda chance seja razoável, 
é desnecessariamente ineficiente porque constantemente 
está movendo páginas em sua lista. Uma abordagem me¬ 
lhor é manter todas as páginas em uma lista circular na 
forma de um relógio, como mostrado na Figura 4-14. Um 
ponteiro indica a página mais antiga. 

Quando uma falha de página ocorre, a página indica¬ 
da pelo ponteiro é inspecionada. Se seu bit R for 0, a pági¬ 
na será expulsa, a nova página será inserida no relógio em 
seu lugar e o ponteiro será avançado uma posição. Se R for 
1, ele será limpo, e o ponteiro é avançado para a próxima 
página. Esse processo é repetido até que uma página seja 
localizada com R = 0. Não é de surpreender que esse algo- 


Página carregada primeiro 



Página mais 

recentemente 

carregada 


(a) 



A é tratada como 
uma página 
recentemente 
carregada 


(b) 


Figura 4-13 A operação de segunda chance, (a) Páginas classificadas pela ordem FIFO. (b) Lista de páginas se uma falha de página 
ocorrer no tempo 20 e A se tiver seu bit R ligado. 
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Quando uma falha de 
página ocorre, a página 
indicada pelo ponteiro é 
examinada. A ação a ser 
executada depende do bit R: 

R = 0: Expulsa a página 
R = 1: Limpa R e avança o ponteiro 


0 0 0 

Figura 4-14 0 algoritmo de substituição de página do relógio. 


ritmo seja chamado de relógio. Ele difere do algoritmo de 
segunda chance somente na implementação. 

4.4.6 Algoritmo de Substituição de 
Página menos Recentemente Utilizada 
(LRU) 

Uma boa aproximação ao algoritmo ótimo é baseada 
na observação de que páginas que foram intensamente uti¬ 
lizadas nas últimas instruções provavelmente serão inten¬ 
samente utilizadas novamente nas seguintes. Inversamen¬ 
te, páginas que não foram utilizadas por muito tempo pro¬ 
vavelmente permanecerão não-utilizadas durante mais 
tempo. Essa idéia sugere um algoritmo realizável: quando 
uma falha de página ocorre, jogue fora a página que não 
foi utilizada por mais tempo. Essa estratégia é chamada 
paginação LRU (Least Recently Used, menos recente¬ 
mente utilizada). 

Embora o LRU seja teoricamente realizável, ele não é 
barato. Para implementar completamente o LRU, é neces¬ 
sário manter uma lista encadeada de todas as página na 
memória, com as páginas mais recentemente utilizadas na 
frente e as menos recentemente utilizadas no fundo. A difi¬ 
culdade é que a lista deve ser atualizada a cada referência 
de memória. A operação de localizar uma página na lista, 
excluí-la e, então, movê-la para a frente consome muito 
tempo, mesmo em hardware (supondo que tal hardware 
pudesse ser construído). 

Entretanto, há outras maneiras de implementar LRU 
com hardware especial. Consideraremos a maneira sim¬ 
ples primeiro. Esse método requer que se equipe o hardwa¬ 
re com um contador de 64 bits, C, que é automaticamente 
incrementado a cada instrução. Além disso, cada entrada 
de tabela de página também deve ter um campo suficien¬ 
temente grande para conter o contador. Após cada referên¬ 
cia de memória, o valor atual de Cé armazenado na entra¬ 
da da tabela de páginas referente à página que for referen¬ 
ciada. Quando uma falha de página ocorre, o sistema ope¬ 


racional examina todos os contadores na tabela de pági¬ 
nas para localizar o menor. Essa página é a menos recen¬ 
temente utilizada. 

Vejamos agora um segundo algoritmo de LRU em har¬ 
dware. Para uma máquina com n molduras de página, o 
hardware de LRU pode manter uma matriz de n x n bits, 
inicialmente todos zero. Sempre que a moldura de página 
k é referenciada, o hardware primeiro configura todos os 
bits da linha k para 1, então, configura todos os bits da 
colunai como 0. Em qualquer instante, a linha cujo valor 
binário é menor é a menos recentemente utilizada, a linha 
cujo valor está imediatamente acima é a próxima menos 
recentemente utilizada, etc. Os trabalhos desse algoritmo 
são dados na Figura 4-15 para quatro molduras de página 
e referências de página na ordem 

0123210323 

Depois que página 0 é referenciada temos a situação da 
Figura 4-15(a) e assim por diante. 

4.4.7 Simulação de LRU em Software 

Embora os dois algoritmos de LRU anteriores sejam re¬ 
alizáveis a princípio, poucas máquinas, se é que alguma, 
têm esse hardware; então, são de pouco valor para o proje¬ 
tista de sistema operacional que está fazendo um sistema 
para uma máquina que não tem esse hardware. Em vez 
disso, é necessária uma solução que possa ser implemen¬ 
tada em software. Uma possibilidade é chamada algoritmo 
não freqüentemente utilizada ou NFU. Ele exige um 
contador de software associado com cada página, inicial¬ 
mente zero. Em cada interrupção de relógio, o sistema ope¬ 
racional varre todas as páginas na memória. Para cada 
página, o bit R, que é 0 ou 1, é adicionado ao contador. De 
fato, os contadores são uma tentativa de monitorar a fre- 
qüência com que cada página foi referenciada. Quando 
ocorre uma falha de página, a página com o contador mais 
baixo é escolhida para substituição. 
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0 12 3 



0 12 3 



0 12 3 



Figura 4-15 LRU utilizando uma matriz. 


0 problema principal com o NFU é que ele nunca se 
esquece de qualquer coisa. Por exemplo, em um compila¬ 
dor de múltiplos passos, as páginas que foram intensamente 
utilizadas durante o passo 1 podem ainda ter uma conta¬ 
gem alta bem depois dos passos seguintes. De fato, se acon¬ 
tecer de o passo 1 ter o tempo de execução mais longo de 
todos os passos, as páginas que contêm o código para os 
passos seguintes sempre podem ter contagens mais baixas 
que as páginas do passo 1. Portanto, o sistema operacional 
removerá páginas úteis em vez de páginas não mais em 
uso. 

Felizmente, uma pequena modificação para o NFU per¬ 
mite que ele simule bem o LRU. A modificação tem duas 
partes. Em primeiro lugar, cada contador é deslocado 1 bit 
à direita antes de o bit R ser adicionado. Em segundo lu¬ 
gar, o bit R é adicionado ao bit mais à esquerda em vez de 
ao bit mais à direita. 

A Figura 4-16 ilustra como o algoritmo modificado, 
conhecido como algoritmo de idade, funciona. Suponha 
que depois do primeiro tique de relógio os bits R para pági¬ 
nas 0 a 5 tenham os valores 1,0,1,0,1 e 1 respectivamente 
(página 0 é 1, página 1 é 0, página 2 é 1 e assim por dian¬ 
te.) Em outras palavras, entre o tique 0 e o tique 1, as pági¬ 
nas 0, 2, 4 e 5 foram referenciadas, configurando seus bits 
R como 1, enquanto os outros permaneceram 0. Depois 
que os seis contadores correspondentes foram deslocados e 
tiveram o bit R inserido à esquerda, eles têm os valores 
mostrados na Figura 4-l6(a). As quatro colunas restantes 
mostram os seis contadores depois dos quatro tiques de re¬ 
lógio seguintes. 

Quando ocorre uma falha de página, a página cujo 
contador é o menor é removida. É claro que uma página 
que não foi referenciada por, digamos, quatro tiques de re¬ 
lógio, terá quatro zeros começando seu contador e, assim, 


terá um valor menor do que um contador que não foi refe¬ 
renciado por três tiques de relógio. 

Esse algoritmo difere do LRU sob dois aspectos. Consi¬ 
dere as páginas 3 e 5 na Figura 4-l6(e). Nenhuma foi refe¬ 
renciada por dois tiques de relógio; ambas foram referen¬ 
ciadas no tique antes disso. De acordo com o LRU, se uma 
página deve ser substituída, devemos escolher uma dessas 
duas. O problema é que não sabemos qual delas foi refe¬ 
renciada pela última vez no intervalo entre o tique 1 e o 
tique 2. Registrando apenas um bit por intervalo de tempo, 
perdemos a capacidade de distinguir entre referências que 
ocorreram mais cedo ou mais tarde no intervalo de um 
tique do relógio. Ilido que podemos fazer é remover a pá¬ 
gina 3. porque a página 5 também foi referenciada dois 
tiques antes e a página 3, não. 

A segunda diferença entre o LRU e a idade é que na 
idade os contadores têm um número finito de bits, 8 bits 
nesse exemplo. Suponha que duas páginas tenham um 
valor de contador 0. Hido que podemos fazer é escolher 
um deles aleatoriamente. Na realidade, é bem possível que 
uma das páginas tenha sido referenciada pela última vez 9 
tiques atrás e a outra tenha sido referenciada por último 
1.000 tiques atrás. Não temos nenhuma maneira de ver 
isso. Na prática, entretanto, 8 bits, em geral, são suficientes 
se um tique de relógio corresponde a algo em tomo de 20ms. 
Se uma página não for referenciada em l60ms, provavel¬ 
mente ela não é importante. 

4.5 QUESTÕES DE PROJETO PARA 
SISTEMAS DE PAGINAÇÃO 

Nas seções anteriores, explicamos como a paginação 
funciona e oferecemos alguns dos algoritmos de substitui- 
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Figura 4-16 0 algoritmo de idade simula I.RU em software. São mostradas seis páginas para cinco tiques de relógio. Os cinco tiques 
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ção de página básicos. Mas conhecer apenas a mecânica 
não é suficiente. Para projetar um sistema, você precisa 
conhecer muito mais para fazê-lo funcionar bem. É como 
a diferença entre saber mover a torre, o cavalo, o bispo e 
outras peças no xadrez e ser um bom jogador. Nas seções a 
seguir, veremos outras questões que projetistas de sistemas 
operacionais devem considerar cuidadosamente a fim de 
obter um bom desempenho de um sistema de paginação. 

4.5.1 Modelo de Conjunto Funcional 

Na forma mais pura de paginação, processos são inici¬ 
ados sem nenhuma de suas páginas na memória. Logo que 
a CPU tenta buscar a primeira instrução, ela obtém uma 
falha de página, fazendo com que o sistema operacional 
traga a página que contém a primeira instrução. Outras 
falhas de página para variáveis globais e para a pilha, em 
geral, seguem-se rapidamente. Depois de um tempo, o pro¬ 
cesso tem a maioria das páginas de que necessita e estabi¬ 
liza-se, executando com relativamente poucas falhas de pá¬ 
gina. Essa estratégia é chamada paginação sob deman¬ 
da porque as páginas são carregadas somente quando são 
necessárias, não antes. 

Naturalmente, é suficientemente fácil escrever um pro¬ 
grama de teste que de forma sistemática leia todas as pági¬ 
nas em um grande espaço de endereços, causando tantas 
falhas de página que não haja memória suficiente para 
armazenar tudo. Felizmente a maioria dos processos não 
funciona assim. Eles apresentam uma referência locali¬ 
zada, indicando que durante qualquer fase de execução, o 


processo referencia somente uma fração relativamente pe¬ 
quena de suas páginas. Cada passagem de um compilador 
de múltiplas passagens, por exemplo, referencia somente 
uma fração de todas as páginas. 

0 conjunto de páginas que um processo está atualmente 
utilizando é chamado conjunto funcional ( workingset) 
(Denning, 1968a; Denning, 1980). Se o conjunto funcio¬ 
nal inteiro estiver na memória, o processo executará sem 
causar muitas falhas até que ele entre em outra fase de 
execução (p. ex., a próxima passagem do compilador). Se 
a memória disponível for muito pequena para armazenar 
o conjunto funcional inteiro, o processo irá causar muitas 
falhas de página e executar lentamente, uma vez que a 
execução de uma instrução freqüentemente leva alguns 
nanossegundos, e a leitura em uma página do disco, em 
geral, leva dezenas de milissegundos. A uma velocidade de 
uma ou duas instruções por 20 milissegundos, ele irá de¬ 
morar muito para terminar. Quando um programa causa 
falhas de página a cada poucas instruções, diz-se que ele 
está criando lixo {thrashing) (Denning, 1968b). 

Em um sistema de compartilhamento de tempo, os pro¬ 
cessos são freqüentemente movidos para disco (i. e., todas 
as suas páginas são removidas da memória) para deixar 
outros processos ter vez na CPU. A pergunta que surge é 
saber o que fazer quando um processo é trazido de volta 
novamente. Tecnicamente, nada precisa ser feito. 0 pro¬ 
cesso simplesmente causará falhas de página até que seu 
conjunto funcional tenha sido carregado. 0 problema é 
que ter 20, 50 ou até 100 falhas de página cada vez que um 
processo é carregado é lento e também desperdiça tempo 
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considerável de CPU, uma vez que o sistema operacional 
leva alguns milissegundos de tempo da CPU para proces¬ 
sar uma falha de página. 

Portanto, muitos sistemas de paginação tentam moni¬ 
torar o conjunto funcional de cada processo e certificar-se 
de que ele está na memória antes de deixar o processo exe¬ 
cutar. Essa abordagem é chamada modelo do conjunto 
funcional (Denning, 1970). Ele foi projetado principal¬ 
mente para reduzir a taxa de falhas de página. Carregar as 
páginas antes de deixar os processos executarem também 
é chamado pré-paginação. 

Para implementar o modelo do conjunto funcional, é 
necessário que o sistema operacional monitore quais pági¬ 
nas estão no conjunto funcional. Uma maneira de moni¬ 
torar essas informações é utilizar o algoritmo de idade dis¬ 
cutido acima. Qualquer página que contenha um bit 1 entre 
os n bits de ordem alta do contador é considerada como 
membro do conjunto funcional. Se uma página não for 
referenciada em n tiques consecutivos de relógio, ela é re¬ 
tirada do conjunto funcional. O parâmetro n tem de ser 
determinado experimentalmente para cada sistema, mas o 
desempenho do sistema normalmente não é especialmen¬ 
te sensível ao valor exato. 

As informações sobre o conjunto funcional podem ser 
utilizadas para melhorar o desempenho do algoritmo do 
relógio. Normalmente, quando o ponteiro indica uma pá¬ 
gina cujo bit/? éO, a página é expulsa. O aprimoramento é 
verificar se essa página é parte do conjunto funcional do 
processo atual. Se for, a página é poupada. Esse algoritmo 
é chamado wsclock. 


4.5.2 Política de Alocação Local 
Versus Global 

Nas seções precedentes, discutimos vários algoritmos 
para escolher uma página para substituir quando ocorre 
uma falha. Uma questão importante associada a essa es¬ 
colha (que cuidadosamente varremos para baixo do tapete 
até agora) é como a memória deve ser alocada entre os 
processos executáveis que competem. 

Dê uma olhada na Figura 4-17(a). Nessa figura, três 
processos,d, B e C, compõem o conjunto de processos exe¬ 
cutáveis. Suponha queri provoque uma falha de página. O 
algoritmo de substituição de página deve tentar localizar a 
página menos recentemente utilizada, considerando so¬ 
mente as seis páginas atualmente alocadas parari ou deve 
considerar todas as páginas na memória? Se olhar somen¬ 
te as páginas de d, a página com o valor de idade mais 
baixo éA5. então, obteremos a situação da Figura 4-17(b) 

Por outro lado, se a página com o valor de idade mais 
baixo for removida sem considerar de quem é essa página, 
a página BJ poderá ser escolhida, e obteremos a situação 
da Figura 4-17(c). O algoritmo da Figura 4-17(b) é cha¬ 
mado algoritmo de substituição de página local, ao passo 
que o da Figura 4-17(c) é chamado algoritmo global. Al¬ 
goritmos locais efetivamente correspondem a alocar para 
cada processo uma fração fixa da memória. Algoritmos glo¬ 
bais alocam dinamicamente molduras de página entre os 
processos executáveis. Assim, o número de molduras de pá¬ 
gina atribuídas a cada processo varia com o tempo. 
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Figura 4-17 Substituição de página localmms global, (a) Configuração original, (b) Substituição de página 
de local, (c) Substituição de página global. 
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Em geral, algoritmos globais funcionam melhor, espe¬ 
cialmente quando o tamanho do conjunto funcional pode 
variar durante o tempo de vida de um processo. Se um al¬ 
goritmo local for utilizado, e o conjunto funcional crescer, 
resultará na criação de lixo, mesmo que haja abundância 
de molduras de página livres. Se o conjunto funcional en¬ 
colher, algoritmos locais desperdiçam memória. Se um al¬ 
goritmo global for utilizado, o sistema deve continuamen¬ 
te decidir quantas molduras de página atribuir a cada pro¬ 
cesso. Uma maneira é monitorar o tamanho do conjunto 
funcional como indicado pelos bits de idade, mas essa abor¬ 
dagem necessariamente não previne a criação de lixo. O 
conjunto funcional pode alterar o tamanho em microsse- 
gundos, ao passo que os bits de idade são uma medida bru¬ 
ta distribuída sobre um número de tiques de relógio. 

Outra abordagem é ter um algoritmo para alocar mol¬ 
duras de página para processos. Uma maneira é periodica¬ 
mente determinar o número de processos em execução e 
alocar para cada processo uma parte igual. Assim com 475 
molduras de página disponíveis (i. e., não-pertencentes ao 
sistema operacional) e 10 processos, cada processo obtém 
47 molduras. As 5 restantes são reservadas para serem uti¬ 
lizadas quando ocorrerem falhas de página. 

Embora esse método pareça justo, faz pouco sentido dar 
partes iguais da memória para um processo de 10K e para 
um processo de 300K. Em vez disso, as páginas podem ser 
alocadas na proporção do tamanho total de cada processo, 
com um processo de 300K obtendo 30 vezes a cota de um 
processo de 10K. Provavelmente é inteligente dar algum 
número mínimo a cada processo, para que ele possa exe¬ 
cutar independentemente de quão pequeno ele seja. Em 
algumas máquinas, por exemplo, uma única instrução 
pode necessitar de até seis páginas porque a própria instru¬ 
ção, o operando da origem e o operando de destino, podem 
ultrapassar os limites da página. Com a alocação de so¬ 
mente cinco páginas, programas que contenham essas ins¬ 
truções não poderão executar. 

Nem a alocação igualitária nem o método de alocação 
proporcional lidam diretamente com o problema de cria¬ 
ção de lixo. Uma maneira mais direta de controlar isso é 


utilizar o algoritmo de alocação por Freqüência de Falha 
de Página (Page Fault Frequency - PFF). Para uma 
classe extensa de algoritmos de substituição de página, in¬ 
cluindo LRU, sabe-se que a taxa de falhas diminui à medi¬ 
da que mais páginas são alocadas, como j á discutimos. Essa 
propriedade é ilustrada na Figura 4-18. 

A linha tracejada^ corresponde a uma taxa de falhas 
de página que é inaceitavelmente alta, então, o processo 
que falha recebe mais molduras de página para reduzir a 
taxa de falhas. A linha tracejada B corresponde a uma taxa 
de falhas de página tão baixa que se pode concluir que o 
processo tem memória demais. Nesse caso, algumas mol¬ 
duras de página podem ser tiradas dele. Assim, o PFF tenta 
manter a taxa de paginação dentro de limites aceitáveis. 

Se o PFF descobre que há tantos processos na memória 
que não é possível mantê-los todos abaixo ded, algum pro¬ 
cesso é removido da memória e suas molduras de página 
são divididas entre os processos que permanecem ou são 
colocados em uma reserva de páginas disponíveis que pode 
ser utilizada em falhas de página subseqüentes. A decisão 
de remover um processo da memória é uma forma de con¬ 
trole de carga. Isso mostra que mesmo com paginação, a 
comutação em disco ainda é necessária, só que agora 
é utilizada para reduzir a exigência potencial para a me¬ 
mória, em vez de reivindicar blocos para utilização imedi¬ 
ata. 

4.5.3 Tamanho de Página 

O tamanho de página é freqüentemente um parâmetro 
que pode ser escolhido pelo sistema operacional. Mesmo se 
o hardware for projetado com, por exemplo, páginas de 512 
bytes, o sistema operacional facilmente pode considerar as 
páginas 0 e 1, 2 e 3,4e5e assim por diante, como páginas 
de 1K, alocando sempre duas molduras de página de 512 
bytes consecutivos para elas. 

Determinar o tamanho ótimo de página exige balan¬ 
cear vários fatores que competem entre si. Para começar, 
um segmento de texto de dados ou de pilha escolhido alea¬ 
toriamente não ocupará um número integral de páginas. 



Figura 4-18 Taxa de falhas de página como uma função do número de molduras de página alocadas. 
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Na média, metade da página final estará vazia. O espaço 
extra naquela página é desperdiçado. Esse desperdício é de¬ 
nominado fragmentação interna. Com n segmentos na 
memória e um tamanho de página de p bytes, np/2 bytes 
serão desperdiçados na fragmentação interna. Esse racio¬ 
cínio argumenta em favor de um tamanho de página pe¬ 
queno. 

Outro argumento para um tamanho de página peque¬ 
no torna-se evidente se pensamos sobre um programa con¬ 
sistindo em oito fases seqüenciais de 4K cada. Com um ta¬ 
manho de página 32K, deve-se alocar ao programa 32K 
todo o tempo. Com um tamanho de página de l6K, é ne¬ 
cessário somente l6K. Com um tamanho de página de 4K 
ou menor, exige-se apenas 4K em qualquer instante. Em 
geral, um tamanho de página grande fará com que os pro¬ 
gramas menos utilizados permaneçam mais na memória 
que com um tamanho de página pequeno. 

Por outro lado, páginas pequenas significam que os 
programas necessitarão de muitas páginas, daí uma tabe¬ 
la de páginas grande. Um programa de 32K precisa somente 
de quatro páginas de 8K, mas de 64 páginas de 512 bytes. 
As transferências para e do disco são geralmente uma pá¬ 
gina por vez, sendo a maior parte do tempo dedicada para 
a busca e para o retardo rotacional, de modo que transferir 
uma página pequena leva quase tanto tempo quanto trans¬ 
ferir uma página grande. Talvez leve 64 x 15ms para car¬ 
regar 64 páginas de 512 bytes, mas somente 4 x 25mspara 
carregar quatro páginas de 8K. 

Em algumas máquinas, a tabela de páginas deve ser 
carregada em registradores de hardware cada vez que a CPU 
alterna de um processo para outro. Nessas máquinas, ter 
um tamanho de página pequeno significa que o tempo so¬ 
licitado para carregar os registradores de página fica mais 
longo conforme o tamanho de página fica menor. Além 
disso, o espaço ocupado pela tabela de páginas aumenta 
conforme diminui o tamanho de página. 

Este último ponto pode ser analisado matematicamen¬ 
te. Suponha que o tamanho médio de um processo sejas' 
bytes e que o tamanho de página seja/> bytes. Além disso, 
suponha que cada entrada de página exija e bytes. O nú¬ 
mero aproximado de páginas necessário por processo é 
então s/p, ocupando se/p bytes de espaço da tabela de pági¬ 
nas. A memória desperdiçada na última página do proces¬ 
so devido à fragmentação internaé p/2. Portanto, o overhe- 
ad total devido à tabela de páginas e à perda por fragmen¬ 
tação interna é dado por 

overhead = se/p + p / 2 

O primeiro termo (tamanho da tabela de páginas) é 
grande quando o tamanho de página é pequeno. O segun¬ 
do termo (fragmentação interna) é grande quando o ta¬ 
manho de página é grande. 0 ótimo deve estar em algum 
lugar entre esses. Fazendo a derivada primeira em relação 
\p e igualando a zero, obtemos a equação 

-se/p 1 +1/2 = 0 


Dessa equação, podemos derivar uma fórmula que dá o 
tamanho ótimo de página (considerando somente a me¬ 
mória desperdiçada na fragmentação e o tamanho da ta¬ 
bela de páginas). O resultado é: 

p = \/2sê 

Parai = 128K e e = 8 bytes por entrada da tabela de pági¬ 
nas, o tamanho ótimo de página é 1448 bytes. Na prática, 
1K ou 2K seriam utilizados, dependendo dos outros fatores 
(p. ex., velocidade do disco). Muitos computadores dispo¬ 
níveis comercialmente utilizam tamanhos de página que 
variam de 512 bytes a 64K. 

4.5.4 Interface de Memória Virtual 

Até agora, nossa conversa inteira assumiu que a me¬ 
mória virtual é transparente para processos e programado¬ 
res, quer dizer, tudo que eles vêem é um grande espaço de 
endereço virtual em um computador com uma memória 
física pequena (menor). Com muitos sistemas, isso é ver¬ 
dadeiro, mas em alguns sistemas avançados, os programa¬ 
dores têm algum controle sobre o mapa de memória e po¬ 
dem empregá-lo de modos não-tradicionais. Nesta seção, 
veremos resumidamente alguns deles. 

Uma razão para dar aos programadores controle sobre 
seu mapa de memória é permitir que dois ou mais proces¬ 
sos compartilhem a mesma memória. Se os programado¬ 
res puderem atribuir nomes a regiões de sua memória, pode 
ser possível para um processo dar o nome de uma região 
de memória para outro processo de modo que este também 
possa mapeá-la. Com dois (ou mais) processos comparti¬ 
lhando as mesmas páginas, torna-se possível o comparti¬ 
lhamento de grande largura de banda — um processo gra¬ 
va na memória compartilhada e outro lê a partir dela. 

O compartilhamento de páginas também pode ser uti¬ 
lizado para implementar um sistema de passagem de men¬ 
sagens de alto desempenho. Normalmente, quando men¬ 
sagens são passadas, os dados são copiados de um espaço 
de endereço para outro, a um custo considerável. Se os pro¬ 
cessos puderem controlar seu mapa de páginas, uma men¬ 
sagem pode ser passada, fazendo o processo remetente des- 
mapear a(s) página(s) que contém(êm) a mensagem, e o 
processo receptor mapeá-las. Aqui somente os nomes de 
página têm de ser copiados, em vez de todos os dados. 

Ainda outra técnica avançada de gerenciamento de 
memória é a memória compartilhada distribuída (Fe- 
eley etal, 1995; Li eHudak, 1989; Zekauskase/tf/.. 1994). 
A idéia aqui é permitir que múltiplos processos sobre uma 
rede compartilhem um conjunto de páginas, possivelmen¬ 
te, mas não necessariamente, como um único espaço de 
endereço linear compartilhado. Quando um processo refe¬ 
rencia uma página que atualmente não está mapeada, ele 
obtém uma falha de página. O manipulador de falha de 
página, que pode estar no kernel ou no espaço de usuário, 
então, localiza a máquina que armazena a página e envia 
uma mensagem solicitando que ele desmapeie a página e 
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envie pela rede. Quando a página chega, ela está mapea¬ 
da, e a instrução que está falhando é reiniciada. 

4.6 SEGMENTAÇÃO 

A memória virtual discutida até agora é unidimensio¬ 
nal porque os endereços virtuais vão de 0 a alguns endere¬ 
ços máximos, um endereço depois do outro. Para muitos 
problemas, ter dois ou mais espaços de endereço virtuais 
separados é muito melhor do que ter apenas um. Por exem¬ 
plo, um compilador tem muitas tabelas que são construí¬ 
das durante a compilação, possivelmente incluindo 

1. O texto fonte sendo salvo para a listagem impressa 
(em sistemas de lote). 

2. A tabela de símbolos, contendo os nomes e os atri¬ 
butos de variáveis. 

3. A tabela contendo todas as constante de número 
inteiro e de ponto flutuante utilizadas. 

4. A árvore de análise, contendo a análise sintática 
do programa. 

5. A pilha utilizada para chamadas de procedimento 
dentro do compilador. 

Cada uma das primeiras quatro tabelas cresce continu¬ 
amente à medida que a compilação procede. A última cresce 
e encolhe de modo imprevisível durante a compilação. Em 
uma memória unidimensional, essas cinco tabelas teriam 
de receber porções contíguas do espaço de endereço virtu¬ 
al, como na Figura 4-19- 

Considere o que acontece se um programa tem um 
número excepcionalmente grande de variáveis. O espaço 
de endereço alocado para a tabela de símbolos pode ser 


totalmente preenchido, mas pode haver muito espaço nas 
outras tabelas. O compilador poderia, naturalmente, sim¬ 
plesmente emitir uma mensagem dizendo que a compila¬ 
ção não continuou devido a variáveis demais, mas fazer 
isso não parece muito esportivo quando espaço não-utili- 
zado é deixado em outras tabelas. 

Outra possibilidade é brincar de Robin Hood, rouban¬ 
do espaço das tabelas com um excesso de espaço e dando 
às tabelas com espaço pequeno. Essa troca pode ser feita, 
mas é análoga a gerenciar seus próprios overlays — um 
aborrecimento no melhor dos casos, e um trabalho muito 
tedioso e desvantajoso no pior. 

O que é realmente necessário é uma maneira de liberar 
o programador de gerenciar a expansão e a contração de 
tabelas, da mesma maneira que a memória virtual elimi¬ 
na a preocupação de organizar o programa em overlays. 

Uma solução extremamente simples e direta é prover a 
máquina com muitos espaços de endereço completamente 
independentes, denominados segmentos. Cada segmento 
consiste em uma seqüência linear de endereços, de 0 até 
algum máximo. O comprimento de cada segmento pode 
ser qualquer coisa de 0 até o máximo permitido. Segmen¬ 
tos diferentes podem e normalmente têm comprimentos 
diferentes. Além disso, os comprimentos dos segmentos 
podem variar durante a execução. 0 comprimento de um 
segmento de pilha pode ser aumentado sempre que algo é 
colocado na pilha e diminuído sempre que algo é retirado 
da pilha. 

Porque cada segmento constitui um espaço de endere¬ 
ço distinto, segmentos diferentes podem crescer ou podem 
encolher independentemente, sem afetar um ao outro. Se 
uma pilha em um certo segmento precisar de mais espaço 
de endereço para crescer, pode tê-lo, porque não há nada 
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Figura 4-19 Em um espaço unidimensional de endereços com tabelas crescentes, uma tabela pode colidir com outra. 
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mais em seu espaço de endereço em que colidir. Natural¬ 
mente, um segmento pode encher-se, mas os segmentos 
são normalmente muito grandes, portanto, essa ocorrên¬ 
cia é rara. Para especificar um endereço nessa memória 
segmentada ou bidimensional, o programa deve fornecer 
um endereço de duas partes, um número de segmento e 
um endereço dentro do segmento. A Figura 4-20 ilustra uma 
memória segmentada sendo utilizada pelas tabelas de com¬ 
pilador discutidas anteriormente. 

Realçamos que um segmento é uma entidade lógica, 
da qual o programador está ciente e à qual ele utiliza como 
uma entidade lógica. Um segmento pode conter um proce¬ 
dimento ou uma matriz, ou uma pilha ou uma coleção de 
variáveis escalares, mas normalmente ele não contém uma 
mistura de tipos diferentes. 

Uma memória segmentada tem outras vantagens além 
de simplificar o tratamento de estruturas de dados que es¬ 
tão crescendo ou encolhendo. Se cada procedimento ocu¬ 
par um segmento separado, com o endereço 0 como seu 
endereço inicial, a linkedição de procedimentos compila¬ 
dos separadamente é muitíssimo simplificada. Depois que 
todos os procedimentos que constituem um programa fo¬ 
ram compilados e linkeditados, uma chamada de procedi¬ 
mento para o procedimento no segmento n utilizará o en¬ 
dereço de duas partes (n, 0) para endereçar a palavra 0 (o 
ponto de entrada). 

Se o procedimento no segmento n for subsequentemente 
modificado e recompilado, nenhum outro procedimento 
precisará ser alterado (porque nenhum dos endereços ini¬ 
ciais foi modificado), mesmo se a nova versão for maior do 
que a antiga. Com uma memória unidimensional, os pro¬ 
cedimentos são empacotados um ao lado do outro, sem 
espaço de endereço entre eles. Portanto, alterar o tamanho 
de um procedimento pode afetar o endereço inicial dos 


outros procedimentos não-relacionados. Isso, por sua vez, 
exige modificar todos os procedimentos que chamam qual¬ 
quer um dos procedimentos movidos, para incorporar seus 
novos endereços iniciais. Se um programa contiver cente¬ 
nas de procedimentos, tal processo pode ser caro. 

A segmentação também facilita compartilhar procedi¬ 
mentos ou dados entre vários processos. Um exemplo co¬ 
mum é a biblioteca compartilhada. Estações de traba¬ 
lho modernas que executam avançados sistemas de jane¬ 
las, com freqüência, têm bibliotecas gráficas extremamen¬ 
te grandes compiladas em quase cada programa. Em um 
sistema segmentado, a biblioteca gráfica pode ser colocada 
em um segmento e compartilhada por múltiplos proces¬ 
sos. eliminando a necessidade de tê-la no espaço de ende¬ 
reço de cada processo. Embora também seja possível ter 
bibliotecas compartilhadas em sistemas de paginação pu¬ 
ros, isso é muito mais complicado. De fato, esses sistemas 
fazem isso simulando segmentação. 

Como cada segmento forma uma entidade lógica de 
que o programador está ciente, tal como um procedimen¬ 
to, uma matriz ou uma pilha, segmentos diferentes podem 
ter tipos de proteção diferentes. Um segmento de procedi¬ 
mento pode ser especificado como de execução somente, 
sendo proibido ler dele ou armazenar nele. Uma matriz de 
ponto flutuante pode ser especificada como de leitura/gra¬ 
vação, mas não de execução, e as tentativas de saltar para 
ela serão interceptadas. Esse tipo de proteção é útil para 
detectar erros de programação. 

Você deve tentar entender por que a proteção faz senti¬ 
do em uma memória segmentada, mas não em uma me¬ 
mória paginada unidimensional. Em uma memória seg¬ 
mentada, o usuário está ciente do que está em cada seg¬ 
mento. Normalmente, um segmento não conteria um pro¬ 
cedimento e uma pilha, por exemplo, mas um ou outro. 
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0 


Segmento 

1 


Segmento 

2 


Segmento 

3 


Segmento 

4 


Figura 4-20 Uma memória segmentada permite que cada tabela cresça ou encolha independentemente das outras tabelas. 
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Uma vez que cada segmento contém somente um tipo de 
objeto, o segmento pode ter a proteção apropriada para esse 
tipo particular. A paginação e a segmentação são compa¬ 
radas na Figura 4-21. 

0 conteúdo de uma página é, em certo sentido, aciden¬ 
tal. 0 programador ignora até mesmo o fato de que a pagi¬ 
nação ocorre. Embora colocar alguns bits em cada entra¬ 
da da tabela de página para especificar o acesso permitido 
seja possível, para utilizar esse recurso o programador te¬ 
ria de monitorar onde os limites de página estão em seu 
espaço de endereço. Isso é precisamente o tipo de adminis¬ 
tração para o qual a paginação foi inventada para elimi¬ 
nar Como o usuário de uma memória segmentada tem a 
ilusão de que todos os segmentos estão na memória princi¬ 
pal o tempo todo — isto é, é possível endereçá-los como se 
estivessem — ele pode proteger cada segmento separada¬ 
mente, sem se preocupar com a administração de overlays. 

4.6.1 Implementação da Segmentação 
Pura 

A implementação de segmentação difere da paginação 
em uma maneira essencial: as páginas têm tamanhos fi¬ 
xos, os segmentos, não. A Figura 4-22 (a) mostra um exem¬ 
plo de memória física inicialmente contendo cinco segmen¬ 
tos. Agora considere o que acontece se o segmento 1 for 
expulso e o segmento 7, que é menor, for colocado em seu 
lugar. Chegamos à configuração de memória da Figura 4- 
22(b). Entre o segmento 7 e o segmento 2, há uma área 
não-utilizada — isto é, uma lacuna. Então, o segmento 4 


é substituído pelo segmento 5, como na Figura 4-22 (c), e o 
segmento 3 é substituído pelo segmento 6, como na Figura 
4-22(d) depois que o sistema tiver executado temporaria¬ 
mente, a memória será dividida em um número de tre¬ 
chos, alguns contendo segmentos e outros contendo lacu¬ 
nas. Esse fenômeno, chamado cbeckerboarding (forma¬ 
ção de um tabuleiro de xadrez) ou fragmentação exter¬ 
na, desperdiça memória nas lacunas. Isso pode ser tratado 
com compactação, como mostrado na Figura 4-22 (e). 

4.6.2 Segmentação com Paginação: 
MULTICS 

Se os segmentos são grandes, pode ser inconveniente, 
ou mesmo impossível, mantê-los na memória principal em 
sua totalidade. Isso leva à idéia de paginá-los, de modo 
que somente as página que realmente são exigidas preci¬ 
sem ficar por perto. Vários sistemas importantes suporta¬ 
ram segmentos paginados. Nesta seção, descreveremos o 
primeiro: MULTICS. Na próxima, discutiremos um mais re¬ 
cente: o Pentium da Intel. 

0 MULTICS rodava nas máquinas Honeywell 6000 e em 
seus descendentes e fornecia a cada programa uma me¬ 
mória virtual de até 2 18 segmentos (mais de 250.000), cada 
um deles podendo ter o comprimento de até 65.536 pala¬ 
vras (de 36 bits). Para implementar isso, os projetistas do 
MULTICS escolheram tratar cada segmento como uma me¬ 
mória virtual e paginá-lo, combinando as vantagens da 
paginação (tamanho de página uniforme e não ter de 
manter 0 segmento inteiro na memória se ao menos parte 
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Figura 4-21 A comparação de paginação e de segmentação. 
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Figura 4-22 (a)-(d) Desenvolvimento da fragmentação externa, (e) Remoção da fragmentação externa por compactação. 
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dele estivesse sendo utilizada) com as vantagens da seg¬ 
mentação (facilidade de programação, modularidade, pro¬ 
teção e compartilhamento). 

Cada programa MULTICS tem uma tabela de segmentos, 
com um descritor por segmento. Uma vez que há potenci¬ 
almente mais que um quarto de milhão de entradas na 
tabela, a tabela de segmentos é, ela própria, um segmento 
e é paginada. Um descritor de segmento contém uma indi¬ 
cação se o segmento está na memória principal ou não. Se 
qualquer parte do segmento estiver na memória, o segmento 
é considerado como estando na memória e sua tabela de 
páginas estará na memória. Se o segmento estiver na me¬ 
mória, seu descritor conterá um ponteiro de 18 bits para 
sua tabela de páginas [veja a Figura 4-23(a) 'na página 
238]. Como os endereços físicos são de 24 bits e as páginas 
são alinhadas em limites de 64 bytes (o que implica que os 
6 bits de ordem inferior dos endereços de página são 
000000), somente 18 bits são exigidos no descritor para 
armazenar um endereço de tabela de página. O descritor 
também contém o tamanho do segmento, os bits de prote¬ 
ção e alguns outros itens. A Figura 4-23(b) (ver página 
238) ilustra um descritor de segmento do multics. O ende¬ 
reço do segmento na memória secundária não está no des¬ 
critor de segmento, mas em outra tabela utilizada pelo ma¬ 
nipulador de falhas de segmento. 

Cada segmento é um espaço de endereço virtual comum 
e é paginado da mesma maneira como a memória pagina¬ 
da não-segmentada descrita anteriormente neste capítulo. 
O tamanho normal de página é 1024 palavras (apesar de 
alguns segmentos pequenos utilizados pelo próprio MUL- 
TICS não serem paginados ou serem paginados em unida¬ 
des de 64 palavras para economizar memória física). 

Um endereço no MULTICS consiste de duas partes: o seg¬ 
mento e o endereço dentro do segmento. O endereço den¬ 
tro do segmento é dividido ainda em um número de pági¬ 


na e uma palavra dentro da página, como mostrado na 
Figura 4-24 (ver página 239)- Quando uma referência de 
memória ocorre, o seguinte algoritmo é executado. 

1. O número do segmento é utilizado para localizar 
o descritor do segmento. 

2. Uma verificação é feita para ver se a tabela de pá¬ 
ginas do segmento está na memória. Se a tabela 
de páginas estiver na memória, ela será localiza¬ 
da. Se não estiver, uma falha de segmento ocorre. 
Se houver uma violação de proteção, uma falha 
ocorre. 

3. A entrada na tabela de páginas para a página vir¬ 
tual solicitada é examinada. Se a página não esti¬ 
ver na memória, uma falha de página ocorre. Se 
estiver na memória, o endereço da memória prin¬ 
cipal referente ao início da página é obtido a par¬ 
tir da entrada na tabela das páginas. 

4. O deslocamento é adicionado à origem da página 
para fornecer o endereço da memória principal 
onde a palavra está localizada. 

5. A leitura ou o armazenamento por fim acontece. 

Esse processo é ilustrado na Figura 4-25 (ver página 
239)- Para simplificar, o fato de que o próprio segmento 
descritor é paginado foi omitido. O que realmente aconte¬ 
ce é que um registrador (o registrador de base do descritor) 
é utilizado para localizar a tabela de páginas do segmento 
descritor, que, por sua vez, aponta para as páginas do seg¬ 
mento descritor. Uma vez que o descritor para o segmento 
necessário foi localizado, o endereçamento procede como 
mostrado na Figura 4-25. 

Como você não tem nenhuma dúvida até agora, se o 
algoritmo precedente realmente fosse executado pelo siste¬ 
ma operacional em cada instrução, os programas não exe¬ 
cutariam muito rapidamente. Na realidade, o hardware do 
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1 = o segmento não é paginado 

Bits diversos - 

Bits de proteção - 

(b) 

Figura 4-23 A memória virtual do MULTICS. (a) 0 segmento descritor aponta para as tabelas de páginas, (b) 
Um descritor de segmento. Os números são os comprimentos dos campos. 


MULTICS contém um TLB de alta velocidade de 16 palavras 
que pode pesquisar todas as suas entradas em paralelo por 
uma dada chave. Isso é ilustrado na Figura 4-26. Quando 
um endereço é apresentado para o computador, o hardwa¬ 
re de endereçamento primeiro verifica se o endereço virtu¬ 
al está no TLB. Se estiver, ele obtém o número na moldura 
de página diretamente do TLB e forma o endereço real da 
palavra referenciada sem olhar no segmento descritor ou 
na tabela de páginas. 

Os endereços das 16 páginas referenciadas mais recen¬ 
temente são mantidos no TLB. Os programas cujo conjun¬ 
to funcional é menor do que o TLB entrarão em equilíbrio 
com os endereços do conjunto funcional inteiro no TLB e, 
portanto, executarão eficientemente. Se a página não esti¬ 


ver no TLB, o descritor e as tabelas de páginas realmente 
são referenciados para localizar o endereço da moldura de 
páginas e o TLB é atualizado para incluir essa página, sen¬ 
do a página menos recentemente utilizada jogada fora. 0 
campo de idade monitora qual entrada é a menos recente¬ 
mente utilizada. A razão por que um TLB é utilizado é para 
comparar o segmento e o número de página de todas as 
entradas em paralelo. 

4.6.3 Segmentação com Paginação: o 
Pentium Intel 

De várias maneiras, a memória virtual do Pentium (e 
do Pentium Pro) assemelha-se à do MULTICS, incluindo a 
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Figura 4-24 Um endereço virtual de 34 bits do MULTICS. 
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Figura 4-25 A conversão de um endereço de duas partes do multics em um endereço na memória principal. 
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Figura 4-26 Uma versão simplificada do TLB do MULTICS. A existência de dois tamanhos de página 
toma o TLB real mais complicado. 
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presença tanto de segmentação como de paginação. En¬ 
quanto o MULTICS tem 25ÔK de segmentos independentes, 
cada um com até 64K palavras de 36 bits, o Pentium tem 
16K segmentos independentes, cada um armazenando até 
1 bilhão de palavras de 32 bits. Embora haja menos seg¬ 
mentos, o tamanho maior de segmento é muito mais im¬ 
portante, uma vez que poucos programas precisam de mais 
de 1.000 segmentos, mas muitos programas precisam de 
segmentos que armazenem megabytes. 

0 coração da memória virtual do Pentium consiste em 
duas tabelas, a LDT (Local Descriptor Table, Tabela 
Local de Descritores) e a GDT (Global Descriptor 
Table, Tabela Global de Descritores). Cada programa 
tem sua própria LDT, mas há uma única GDT, comparti¬ 
lhada por todos os programas no computador. A LDT des¬ 
creve segmentos locais para cada programa, incluindo seu 
código, seus dados, sua pilha, etc., ao passo que a GDT des¬ 
creve segmentos do sistema, incluindo o próprio sistema 
operacional. 

Para acessar um segmento, um programa Pentium pri¬ 
meiro carrega um seletor para esse segmento em um dos 
seis registradores de segmento da máquina. Durante a exe¬ 
cução, o registrador CS armazena o seletor para o segmen¬ 
to de código, e o registrador DS armazena o seletor para o 
segmento de dados. Os outros registradores de segmento 
são menos importantes. Cada seletor é um número de l6 
bits, como mostrado na Figura 4-27. 

Um dos bits do seletor diz se o segmento é local ou glo¬ 
bal (i. e., se está na LDT ou na GDT). Treze outros bits 
especificam o número da entrada na LDT ou na GDT, logo 
essas tabelas são restringidas ao armazenamento de 8K de 
descritores de segmento. Os outros 2 bits relacionam-se com 
proteção e serão descritos mais tarde. 0 descritor 0 é proi¬ 
bido. Ele pode ser seguramente carregado em um registra¬ 
dor de segmento para indicar que o registrador de segmen¬ 
to não está atualmente disponível. Se utilizado, causa uma 
interrupção. 

No momento em que um seletor é carregado em um 
registrador de segmento, o descritor correspondente é bus¬ 
cado na LDT ou na GDT e annazenado em registradores de 
microprograma, para que possa ser acessado rapidamente. 
Um descritor consiste em 8 bytes, incluindo o endereço de 
base, o tamanho e outras informações do segmento, como 
representado na Figura 4-28. 

0 formato do seletor foi inteligentemente escolhido para 
facilitar a localização do descritor. Primeiro a LDT ou a 
GDT é selecionada, com base no bit 2 do seletor. Então, o 

Bits 13 


seletor é copiado para um registrador interno, e os 3 bits de 
ordem inferior são configurados como 0. Por fim, o ende¬ 
reço da tabela LDT ou GDT é adicionado a ele para forne¬ 
cer um ponteiro direto para o descritor. Por exemplo, o se¬ 
letor 72 refere-se à entrada 9 na GDT, que está localizada 
no endereço GDT + 72. 

Vamos rastrear os passos por meio dos quais um par 
(seletor, deslocamento) é convertido em um endereço físi¬ 
co. Logo que o microprograma sabe qual registrador de 
segmento está sendo utilizado, ele pode localizar o descri¬ 
tor completo correspondente a esse seletor em seus regis¬ 
tradores internos. Se o segmento não existe (seletor 0), ou 
está atualmente paginado fora, ocorre uma interrupção. 

Então, ele verifica se o deslocamento está além do fim 
do segmento, caso em que uma interrupção também ocor¬ 
re. Logicamente, deve haver simplesmente um campo de 
32 bits no descritor que dá o tamanho do segmento, mas 
há somente 20 bits disponíveis; então, um esquema dife¬ 
rente é utilizado. Se o campo Gbit (Granulação) é 0, o cam¬ 
po Limit é o tamanho exato de segmento, até 1MB. Se é 1, 
o campo Limit dá o tamanho do segmento em páginas em 
vez de bytes. O tamanho de página do Pentium é fixo em 
4K bytes, logo 20 bits são suficientes para segmentos de até 
2 32 bytes. 

Supondo que o segmento esteja na memória, e o deslo¬ 
camento esteja no intervalo, o Pentium, então, adiciona o 
campo Base de 32 bits do descritor ao deslocamento para 
formar o que se chama endereço linear, como mostrado 
na Figura 4-29. O campo Base é dividido em três partes e 
distribuído pelo descritor para manter compatibilidade com 
os 286, nos quais o campo Base é de apenas 24 bits. Com 
efeito, o campo Base permite que cada segmento inicie em 
um lugar arbitrário dentro do espaço de endereço linear de 
32 bits. 

Se a paginação for desativada (por um bit em um re¬ 
gistrador de controle global), o endereço linear é interpre¬ 
tado como o endereço físico e enviado para a memória para 
leitura ou para gravação. Assim, com a paginação desati¬ 
vada, temos um esquema de segmentação puro, com o en¬ 
dereço de base de cada segmento dado em seu descritor. Os 
segmentos podem sobrepor-se, casualmente, provavelmente 
porque seria problema demais e tomaria muito tempo ve¬ 
rificar se todos eles estariam disjuntos. 

Por outro lado, se a paginação estiver ativada, o ende¬ 
reço linear será interpretado, como um endereço virtual e 
mapeado para o endereço físico, utilizando as tabelas de 
páginas, de maneira muito parecida com nossos exemplos 
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Figura 4-27 Um seletor do Pentium. 
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Figura 4-28 0 descritor de segmento de código de Pentium. Os segmentos de dados diferem ligeiramente. 


anteriores. A única complicação real é que com um ende¬ 
reço virtual de 32 bits e uma página de 4K, um segmento 
pode conter 1 milhão de páginas, então, um mapeamento 
de dois níveis é utilizado para reduzir o tamanho da tabela 
de páginas para segmentos pequenos. 

Cada programa em execução tem um diretório de 
páginas que consiste em 1024 entradas de 32 bits. Ele está 
localizado em um endereço apontado por um registrador 
global. Cada entrada nesse diretório aponta para uma ta¬ 
bela de páginas também contendo 1024 entradas de 32 bits. 
As entradas da tabela de páginas apontam para molduras 
de página. O esquema é mostrado na Figura 4-30. 

Na Figura 4-30(a), vemos um endereço linear dividido 
em três campos, Dir, Page eOff.O campo Dir é utilizado 
como índice no diretório de páginas a fim de localizar um 
ponteiro para a tabela de páginas adequada. Então, o campo 
Page é utilizado como um índice na tabela de páginas para 
localizar o endereço físico da moldura de páginas. Por fim, 
Off é adicionado ao endereço da moldura de página para 
obter o endereço físico do byte ou da palavra necessária. 

As entradas da tabela de páginas são de 32 bits cada, 20 
dos quais contêm um número de moldura de página. Os 
bits restantes contêm bits de acesso e bits sujos, configura¬ 


dos pelo hardware para benefício do sistema operacional, 
bits de proteção e outros bits de utilidade. 

Cada tabela de página tem entradas para 1024 moldu¬ 
ras de página de 4K; portanto, uma única tabela de páginas 
trata 4 megabytes de memória. Um segmento com menos 
de 4M terá um diretório de páginas com uma única entra¬ 
da e com um ponteiro para sua única tabela de páginas. 
Dessa maneira, o overhead para segmentos curtos é de so¬ 
mente duas páginas, em vez de um milhão de páginas que 
seriam requeridas na tabela de páginas de nível único. 

Para evitar fazer referências repetidas à memória, o 
Pentium, como o MULTICS, tem um pequeno TLB que ma- 
peia diretamente as combinações Diretório-Página utili¬ 
zadas mais recentemente para o endereço físico da moldu¬ 
ra de página. Somente quando a combinação atual não 
está presente no TLB é que o mecanismo da Figura 4-30 é 
realmente executado e o TLB atualizado. 

Pensando um pouco, descobrimos que o fato de que 
quando a paginação é utilizada, não há realmente nenhum 
motivo para ter o campo Base no descritor como diferente 
de zero. Tudo que o campo Base faz é causar um pequeno 
deslocamento para utilizar uma entrada no meio do dire¬ 
tório de páginas, em vez de no começo. A verdadeira razão 



Figura 4-29 A conversão de um par (seletor, deslocamento) em um endereço linear. 
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Figura 4-30 Mapeamento de um endereço linear para um endereço físico. 


para incluir Base no final das contas é permitir segmenta¬ 
ção pura (hão-paginada) e por questão de compatibilida¬ 
de com os 286, que têm a paginação sempre desativada (i. 
e., os 286 têm somente segmentação pura, mas não pagi¬ 
nação). 

Também vale notar que se algum aplicativo não neces¬ 
sita de segmentação, mas está contente com um único es¬ 
paço de endereço de 32 bits paginado, esse modelo é possí¬ 
vel. Todos os registradores de segmento podem ser configu¬ 
rados com o mesmo seletor, cujo descritor tem Base = 0 e 
Limite configurado como o máximo. 0 deslocamento da 
instrução, então, será o endereço linear, com somente um 
único espaço de endereço utilizado — com efeito, uma 
paginação normal. 

Em suma, devemos congratular os projetistas do Pen¬ 
tium. Dado os objetivos contraditórios de implementar pa¬ 
ginação pura, segmentação pura e segmentos paginados, 
e, ao mesmo tempo, ser compatível com os 286 e fazer tudo 
isso eficientemente, o projeto resultante é surpreendente¬ 
mente simples e limpo. 

Embora tenhamos abordado a arquitetura completa da 
memória virtual do Pentium, mesmo que resumidamente, 
vale dizer algumas palavras sobre a proteção, uma vez que 
esse assunto está intimamente relacionado com a memó¬ 
ria virtual. Assim como o esquema de memória virtual é 
bastante semelhante ao modelado no MULTICS, o sistema 
de proteção também o é. 0 Pentium suporta quatro níveis 
de proteção, com o nível 0 sendo o mais privilegiado, e o 
nível 3 o menos. Esses são mostrados na Figura 4-31. Em 
cada instante, um programa em execução está em um cer¬ 


to nível, indicado por um campo de 2 bits em seu PSW. 
Cada segmento no sistema também tem um nível. 

Contanto que um programa restrinja-se a utilizar seg¬ 
mentos no seu próprio nível, tudo funciona bem. As tenta¬ 
tivas de acessar dados em um nível mais alto são permiti¬ 
das. As tentativas de acessar dados em um nível mais baixo 
são ilegais e geram interrupções. As tentativas de chamar 
procedimentos em um nível diferente (acima ou abaixo) 
são permitidas, mas de uma maneira cuidadosamente con¬ 
trolada. Para fazer uma chamada internível, a instrução 
CALL deve conter um seletor em vez de um endereço. Esse 
seletor designa um descritor chamado portão de chama¬ 
da ( call gate), o qual dá o endereço do procedimento a 
ser chamado. Assim, não é possível saltar no meio de um 
segmento de código arbitrário em um nível diferente. So¬ 
mente pontos de entrada oficiais podem ser utilizados. Os 
conceitos de níveis de proteção e de portões de chamada 
foram desbravados no MULTICS, onde foram vistos como 
anéis de proteção. 

Uma utilização típica para esse mecanismo é sugerida 
na Figura 4-31. No nível 0, localizamos o kernel do siste¬ 
ma operacional, que trata a E/S, o gerenciamento de me¬ 
mória e outras questões críticas. No nível 1, o manipulador 
de chamadas do sistema está presente. Os programas de 
usuário podem chamar procedimentos aqui para fazer as 
chamadas de sistema executarem, mas somente uma lista 
específica e protegida de procedimentos pode ser chama¬ 
da. O nível 2 contém procedimentos de biblioteca, possi¬ 
velmente compartilhados entre muitos programas em exe¬ 
cução. Os programas de usuário podem chamar esses pro- 
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cedimentos e ler seus dados, mas não podem modificá-los. 
Por fim, os programas de usuário executam no nível 3, 
que tem a menor proteção. 

Interrupções utilizam um mecanismo semelhante aos 
portões de chamada. Elas também referenciam descrito¬ 
res, em vez de endereços absolutos, e esses descritores apon¬ 
tam para procedimentos específicos a serem executados. 0 
campo Type na Figura 4-28 distingue entre segmentos de 
código, segmentos de dados e os vários tipos de portões. 

4.7 VISÃO GERAL DO 
GERENCIAMENTO DE MEMÓRIA NO 
MINIX 

0 gerenciamento de memória no MINIX é simples: não 
se utiliza paginação nem troca. 0 gerenciador de memória 
mantém uma lista de lacunas classificadas pela ordem de 
endereço de memória. Quando memória é necessária, de¬ 
vido a uma chamada de sistema FORK ou EXl-X, a lista de 
lacunas é pesquisada, utilizando o algoritmo do primeiro 
ajuste para uma lacuna que seja suficientemente grande. 
Uma vez que um processo foi colocado na memória, ele 
permanece exatamente no mesmo lugar até terminar. Ele 
nunca é enviado para disco e também nunca é movido para 
outro lugar na memória. Tampouco faz a área alocada cres¬ 
cer ou encolher. 

Essa estratégia merece alguma explicação. Ela deriva 
de três fatores: (1) a idéia de que o MINIX destina-se a com¬ 
putadores pessoais e não a sistemas de compartilhamento 
de tempo de grande porte; (2) o desejo de ter o minix funci¬ 
onando em todos os IBM PC e (3) o desejo de tornar sim¬ 
ples e direta a implementação do sistema em outros com¬ 
putadores pequenos. 


0 primeiro fato significa que, na média, o número de 
processos em execução será pequeno, de modo que, em ge¬ 
ral, haverá memória disponível suficiente para armazenar 
todos os processos com espaço de sobra. A troca em disco, 
então, não será exigida. Como acrescenta complexidade 
ao sistema, não fazer troca torna o código mais simples. 

0 desejo de ter o minix executando em todos os compu¬ 
tadores compatíveis com IBM PC também teve um impac¬ 
to significativo no projeto do gerenciamento de memória. 
Os sistemas mais simples nessa família utilizam o proces¬ 
sador 8088, cuja arquitetura de gerenciamento de memó¬ 
ria é muito primitiva. Ela não suporta memória virtual sob 
qualquer forma e nem mesmo detecta estouro de pilha, 
um defeito que tem implicações importantes sobre a ma¬ 
neira com que os processos são dispostos na memória. Tais 
limitações não existem na maioria dos projetos posteriores 
que utilizam os processadores 80386, 80486 ou Pentium. 
Entretanto, tirar proveito desses recursos tornaria o MINIX 
incompatível com muitas máquinas de categoria inferior 
que ainda são aproveitáveis e estão em uso. 

A questão de portabilidade argumenta em favor do mais 
simples esquema de gerenciamento de memória possível. 
Se o minix utilizasse paginação ou segmentação, seria difí¬ 
cil, se não impossível, portá-lo para máquinas que não têm 
esses recursos. Fazendo o menor número possível de supo¬ 
sições quanto ao hardware, o número de máquinas para as 
quais o MINIX poder ser portado aumenta. 

Outro aspecto incomum do minix é a maneira como o 
gerenciamento de memória é implementado. Ele não é 
parte do kernel. Em vez disso, ele é tratado pelo processo 
gerenciador de memória, que executa no espaço do usuá¬ 
rio e comunica-se com o kernel pelo mecanismo padrão 
de mensagens. A posição do gerenciador de memória no 
nível de servidor é mostrada na Figura 2-26. 
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Mover o gerenciador de memória para fora do kernel é 
um exemplo da separação entre política e mecanismo. 
As decisões sobre quais processos serão colocados em quais 
lugares na memória (política) são feitas pelo gerenciador 
de memória. A configuração real dos mapas de memória 
para os processos (mecanismo) é feita pela tarefa de siste¬ 
ma dentro do kernel. Essa divisão torna relativamente fá¬ 
cil alterar a política de gerenciamento de memória (algo¬ 
ritmos, etc.) sem modificar as camadas mais baixas do sis¬ 
tema operacional. 

A maior parte do código do gerenciador de memória é 
dedicada ao tratamento das chamadas de sistema do MINIX 
que envolvem gerenciamento de memória, principalmen¬ 
te FORK e EXEC, em vez de apenas manipular listas de pro¬ 
cessos e lacunas. Na próxima seção, veremos o layout da 
memória e, em seções posteriores, daremos uma passada 
de olhos em como as chamadas de sistema de gerencia¬ 
mento de memória são processadas pelo gerenciador de me¬ 
mória. 

4.7.1 Leiaute de Memória 

Processos simples do minix utilizam espaços I e D com¬ 
binados, em que todas as partes do processo (texto, dados e 
pilha) compartilham um bloco de memória que é alocado 
e liberado como um bloco. Os processos tambe'm podem 
ser compilados para utilizar espaços I e D separados. Para 
tomar o assunto mais claro, primeiro será discutida a alo¬ 
cação de memória para o modelo mais simples. Os proces¬ 
sos que utilizam espaços I e D separados podem utilizar 
memória mais eficientemente, mas tirar proveito desse re¬ 
curso complica as coisas. Discutiremos as complicações 
depois de delinear o caso mais simples. 

A memória é alocada no minix em duas ocasiões. Em 
primeiro lugar, quando um processo cria um filho, a quan¬ 
tidade de memória necessária para o filho é alocada. Em 
segundo lugar, quando um processo altera sua imagem de 
memória via chamada de sistema EXEC, a imagem antiga 
é retornada à lista livre como uma lacuna, e memória é 



(a) 


alocada para a nova imagem. A nova imagem pode estar 
em uma parte da memória diferente da memória liberada. 
Sua posição dependerá de onde uma lacuna adequada é 
encontrada. A memória também é liberada sempre que um 
processo termina, seja saindo normalmente ou eliminado 
por um sinal. 

A Figura 4-32 mostra as duas maneiras de alocar me¬ 
mória. Na Figura 4-32(a), vemos dois processos,/! e B. na 
memória. Se/l cria um filho, obtemos a situação da Figura 
43-2 (b). O filho é uma cópia exata de d. Se o filho agora 
executar o arquivo C, a memória ficará parecida com a 
Figura 4-32(c). A imagem do filho é substituída por C. 

Note que a memória antiga para o filho é liberada an¬ 
tes de a nova memória para C ser alocada, para que C pos¬ 
sa utilizar a memória do filho. Dessa maneira, uma série 
de pares FORK e exec (tal como o shell configurando uma 
canalização) resulta em todos os processos serem adjacen¬ 
tes, sem lacunas entre eles, como seria o caso se a nova 
memória tivesse sido alocada antes de a memória antiga 
ter sido liberada. 

Quando a memória é alocada, seja por FORK seja por 
EXEC, uma certa quantidade é tomada para o novo proces¬ 
so. No primeiro caso, a quantidade tomada é idêntica à 
que o processo do pai tem. No último caso, o gerenciador 
de memória toma a quantidade especificada no cabeçalho 
do arquivo executado. Uma vez que essa alocação foi feita, 
sob nenhuma condição o processo aloca mais memória. 

O que foi dito até agora aplica-se a programas que fo¬ 
ram compilados com os espaços I e D combinados. Os pro¬ 
gramas com espaços I e D separados tiram proveito de um 
modo expandido de gerenciamento de memória denomi¬ 
nado texto compartilhado. Quando tal processo faz um 
fork, somente a quantidade de memória necessária para 
uma cópia dos dados e da pilha do novo processo é aloca¬ 
da. Ambos, pai e filho, compartilham o código executável 
já em uso pelo pai. Quando tal processo faz um exec, é 
feita uma pesquisa na tabela de processos para ver se outro 
processo já está utilizando o código executável necessário. 
Se um for localizado, nova memória é alocada somente para 
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Figura 4-32 A alocação de memória, (a) Originalmente, (b) Depois de um fork. (c) Depois que o filho fez 
um exec. As regiões sombreadas correspondem à memória livre. O processo é do tipo I&D comuns. 
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os dados e para a pilha, enquanto o texto já na memória é 
compartilhado. Texto compartilhado complica a termina¬ 
ção de um processo. Quando um processo termina, ele sem¬ 
pre libera a memória ocupada por seus dados e pela pilha. 
Mas ele somente libera a memória ocupada por seu seg¬ 
mento de texto depois que uma pesquisa na tabela de pro¬ 
cessos revela que nenhum outro processo está compartilhan¬ 
do essa memória. Assim, pode ser alocada mais memória a 
um processo quando ele inicia do que é liberada quando 
ele termina, se ele carregou o próprio texto quando iniciou, 
mas esse texto está sendo compartilhado por um ou mais 
outros processos quando o primeiro processo termina. 

A Figura 4-33 mostra como um programa é armazena¬ 
do na forma de um arquivo de disco e como isso é transfe¬ 
rido para o arranjo interno de memória de um processo 
MINIX. 0 cabeçalho no arquivo de disco contém as infor¬ 
mações sobre os tamanhos das diferentes partes da ima¬ 
gem, assim como o tamanho total. No cabeçalho de um 
programa com espaços I e D comuns, um campo especifi¬ 
ca o tamanho total das partes de texto e de dados; essas 
partes são copiadas diretamente para a imagem da memó¬ 
ria. A parte de dados na imagem é aumentada pela quanti¬ 
dade especificada no campo bss no cabeçalho. Essa área é 
limpa para conter apenas zeros e é utilizada para dados 
estáticos não-inicializados. A quantidade total de memó¬ 
ria a ser alocada é especificada pelo campo total no cabe¬ 
çalho. Se, por exemplo, um programa tem 4K de texto, 2K 
de dados mais bss e 1K de pilha, e o cabeçalho diz para 
alocar 40K no total, a lacuna de memória não-utilizada 
entre o segmento de dados e o segmento de pilha será de 
33K. Um arquivo de programa no disco também pode con¬ 
ter uma tabela de símbolos. Esta última é para uso na de¬ 
puração e não é copiada para a memória. 

Se o programador souber que a memória total necessá¬ 
ria para o crescimento dos segmentos de dados e de pilha 
combinados para o arquivo a.out é no máximo 10K, ele 
pode dar o comando 

chmem =10240 a.out, 

o que altera o campo de cabeçalho de modo que, no mo¬ 
mento do EXEC, o gerenciador de memória aloca um espa¬ 


ço de 10240 bytes mais que a soma dos segmentos de texto 
e dados iniciais. Para o exemplo acima, um total de 16K 
será alocado em todos os subseqüentes EXECs do arquivo. 
Dessa quantidade, os 1K superiores serão utilizados para a 
pilha, e os 9K restantes estarão na lacuna, onde podem ser 
utilizados para o crescimento da pilha, da área de dados 
ou ambos. 

Para um programa que utiliza espaços I e D separados 
(indicado por um bit no cabeçalho que é configurado pelo 
linkeditor), o campo total no cabeçalho aplica-se somente 
aos espaços de dados e de pilha combinados. Para um pro¬ 
grama com 4K de texto, 2K de dados, 1K de pilha e um 
tamanho total de 64K serão alocados 68K (4K de espaço de 
instruções, 64K de espaço de dados), deixando 6lK para o 
segmento de dados e a pilha consumirem durante a execu¬ 
ção. O limite do segmento de dados pode ser movido so¬ 
mente pela chamada de sistema BRK. Túdo que a brk faz é 
verificar se o novo segmento de dados colide com o pontei¬ 
ro atual da pilha e, se não, anotar a alteração em algumas 
tabelas internas. Isso é inteiramente interno à memória 
originalmente alocada para o processo; nenhuma memó¬ 
ria adicional é alocada pelo sistema operacional. Se o novo 
segmento de dados colide com a pilha, a chamada falha. 

Essa estratégia foi escolhida para tornar possível exe¬ 
cutar o MINIX em um IBM PC com um processador 8088, 
que não verifica estouro de pilha em hardware. Um pro¬ 
grama de usuário pode empurrar tantas palavras quanto 
quiser sobre a pilha sem que o sistema operacional esteja 
ciente disso. Em computadores com hardware de gerencia¬ 
mento de memória mais sofisticado, é alocada uma certa 
quantidade de memória para a pilha inicialmente. Se esta 
última tentar crescer além dessa quantidade, ocorre uma 
interrupção para o sistema operacional, e o sistema aloca 
outro pedaço de memória para a pilha, se possível. Essa 
interrupção não existe nos 8088, tornando perigoso ter a 
pilha adjacente a qualquer coisa exceto um trecho grande 
de memória não-utilizada, uma vez que a pilha pode cres¬ 
cer rapidamente e sem aviso. O MINIX foi projetado de modo 
que quando é implementado em um computador com 
melhor gerenciamento de memória, é simples e direto al¬ 
terar o gerenciador de memória do minix. 
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Figura 4-33 (a) Um programa como armazenado em um arquivo de disco, (b) Arranjo interno de memória para um único processo. 

Nas duas partes da figura, o disco ou o endereço de memória mais baixo está no fundo, e o endereço mais alto está no topo. 
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Este é um bom lugar para mencionar uma possível di¬ 
ficuldade semântica. Quando utilizamos a palavra “seg¬ 
mento”, referimo-nos a uma área da memória definida pelo 
sistema operacional. Os processadores Intel 80x86 têm um 
conjunto interno de “registradores de segmento” e (nos 
processadores mais avançados) “tabelas de descritores de 
segmentos” que oferecem suporte de hardware para “seg¬ 
mentos”. O conceito de segmento dos projetistas de har¬ 
dware da Intel é semelhante, mas não é sempre o mesmo 
que os segmentos utilizados e definidos pelo minix. Todas 
as referências a segmentos neste texto devem ser interpre¬ 
tadas como referências a áreas da memória delineadas pe¬ 
las estruturas de dados do MINIX. Vamos nos referir explici¬ 
tamente a registradores de segmento ou a descritores de 
segmento quando falarmos sobre o hardware. 

Essa advertência pode ser generalizada. Os projetistas 
de hardware freqüentemente tentam proporcionar suporte 
ao sistema operacional que eles esperam ser utilizado em 
suas máquinas, e a terminologia utilizada para descrever 
registradores e outros aspectos de uma arquitetura de pro¬ 
cessador normalmente reflete uma idéia de como os recur¬ 
sos serão utilizados. Tais recursos são freqüentemente úteis 
para o implementador de um sistema operacional, mas eles 
podem não ser utilizados da mesma maneira que o proje¬ 
tista de hardware previu. Isso pode levar a mal-entendidos 
quando a mesma palavra tiver significados diferentes quan¬ 
do utilizada para descrever um aspecto de um sistema ope¬ 
racional ou do hardware subjacente. 

4.7.2 Processamento de Mensagens 

Como todos os outros componentes do MINIX, o geren¬ 
ciador de memória é baseado em mensagens. Depois que o 
sistema foi iniciado, o gerenciador de memória entra no 
seu laço principal, que consiste em esperar uma mensa¬ 
gem, em executar a solicitação contida na mensagem e 
em enviar uma resposta. A Figura 4-34 fornece a lista de 
tipos de mensagem válidos, seus parâmetros de entrada e o 
valor enviado de volta na mensagem de resposta. 

fork, EXIT, wait, WAITPID. BRK e EXEC estão, claramen¬ 
te, intimamente relacionadas com alocação e com desalo- 
cação de memória. As chamadas kill, alarm e pause são, 
todas relacionadas a sinais, assim como o são SIGACTION, 
SIGSUSPEND, SIGPENDING, SIGMASK e SIGRETURN. Estas Últi¬ 
mas também podem afetar o que está na memória, por¬ 
que, quando um sinal elimina um processo, a memória do 
processo é desalocada. REBOOT tem efeitos por todo o siste¬ 
ma operacional, mas seu primeiro trabalho é enviar sinais 
para terminar todos os processos de uma maneira contro¬ 
lada; assim, o gerenciador de memória é um bom lugar 
para ele. As sete chamadas GET/SET não têm absolutamen¬ 
te nada a ver com gerenciamento de memória. Elas tam¬ 
bém não têm nada a ver com o sistema de arquivos. Mas 
elas precisam entrar no sistema de arquivos ou no gerenci¬ 
ador de memória, uma vez que cada chamada de sistema é 
tratada por um ou por outro. Elas foram colocadas aqui 
simplesmente porque o sistema de arquivos já estava sufi¬ 


cientemente grande. PTRACE, que é utilizada em depura¬ 
ção, está aqui pela mesma razão. 

A mensagem final, KSIG, não é uma chamada de siste¬ 
ma. KSIG é o tipo de mensagem utilizado pelo kernel para 
informar o gerenciador de memória sobre um sinal que se 
origina no kernel, como SIGIXT, SIGQUIT ou SIGAI.RM. 

Embora haja uma rotina de biblioteca sbrk, não há 
nenhuma chamada de sistema SBRK. A rotina de biblioteca 
computa a quantidade de memória necessária, adicionan¬ 
do ao tamanho atual incremento ou decremento especifi¬ 
cado como parâmetro e faz uma chamada BRK para confi¬ 
gurar o tamanho. De maneira semelhante, não há cha¬ 
madas de sistema separadas para geteuid ege/egid. As cha¬ 
madas GETUID e GETGID retornam ambos os identificado¬ 
res reais e efetivos. De maneira semelhante, getpid retor¬ 
na o pid do processo de chamada e de seu pai. 

Uma estrutura de dados-chave utilizada para processa¬ 
mento de mensagens é a tabela call_vec declarada em 
table.c (linha 16515). Ela contém ponteiros para os proce¬ 
dimentos que tratam os vários tipos de mensagens. Quan¬ 
do uma mensagem entra no gerenciador de memória, o 
laço principal extrai o tipo de mensagem e coloca na vari¬ 
ável global mm_çall. Esse valor é, então, utilizado como 
índice em callvec a fim de localizar o ponteiro para o pro¬ 
cedimento que trata a mensagem recém-chegada. Esse pro¬ 
cedimento, então, é chamado para executar a chamada de 
sistema. O valor que ele retorna é enviado de volta para o 
chamador na mensagem de resposta, a fim de informar 
sobre o sucesso ou sobre fracasso da chamada. Esse meca¬ 
nismo é semelhante ao da Figura 1-16, só que no espaço 
do usuário em vez de no espaço do kernel. 

4.7.3 Estruturas de Dados e 
Algoritmos do Gerenciador de Memória 

O gerenciador de memória tem duas estruturas de da¬ 
dos-chave: a tabela de processos e a tabela de lacunas. Ago¬ 
ra veremos cada uma delas individualmente. 

Na Figura 2-4 vimos que alguns campos da tabela de 
processos são necessários para o gerenciamento de proces¬ 
so, outros para o gerenciamento de memória e outros ain¬ 
da para o sistema de arquivos. No minix, cada uma dessas 
três partes do sistema operacional tem sua própria tabela 
de processos, contendo somente os campos de que ela ne¬ 
cessita. Para simplificar as coisas, as entradas correspon- 
dem-se exatamente. Assim, a entrada k da tabela do geren¬ 
ciador de memória refere-se ao mesmo processo que a en¬ 
trada k da tabela do sistema de arquivos. Quando um pro¬ 
cesso é criado ou destruído, todas as três partes atualizam 
suas tabelas para refletir a nova situação, a fim de mantê- 
las sincronizadas. 

A tabela de processos do gerenciador de memória é cha¬ 
mada mproc; sua definição está em /usr/src/mm/mproc.h. 
Ela contém todos os campos relacionados com a alocação 
de memória de um processo, assim como alguns itens adi¬ 
cionais. O campo mais importante é a matriz mp_seg, que 
tem três entradas, para os segmentos de texto, dados e pi- 
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Tipo da mensagem 

Parâmetros da entrada 

Valor da resposta 

FORK 

(nenhum) 

Pid do filho, (para filho: 0) 

EXIT 

Status da saída 

(Nenhuma resposta se bem-sucedida) 

WAIT 

(nenhum) 

Status 

WAITPID 

(nenhum) 

Status 

BRK 

Novo tamanho 

Novo tamanho 

EXEC 

Ponteiro para pilha inicial 

(Nenhuma resposta se bem-sucedida) 

KILL 

Identificador do processo e do sinal 

Status 

ALARM 

Número de segundos a esperar 

Tempo residual 

PAUSE 

(nenhum) 

(Nenhuma resposta se bem-sucedida) 

SIGACTION 

Número do sinal, ação, ação antiga 

Status 

SIGSUSPEND 

Máscara de sinal 

(Nenhuma resposta se bem-sucedida) 

SIGPENDING 

(nenhum) 

Status 

SIGMASK 

Como configuração, configuração antiga 

Status 

SIGRETURN 

Contexto 

Status 

GETUID 

(nenhum) 

Uid, uid efetivo 

GETGID 

(nenhum) 

Gid, gid efetivo 

GETPID 

(nenhum) 

Pid, pid do pai 

SETUID 

Novo uid 

Status 

SETGID 

Novo gid 

Status 

SETSID 

Novo sid 

Grupo do processo 

GETPGRP 

Novo gid 

Grupo do processo 

PTRACE 

Solicitação, pid, endereço, dados 

Status 

REBOOT 

Como (suspende, reinicializa ou pane) 

(Nenhuma resposta se bem-sucedida) 

KSIG 

Entrada de processos e de sinais 

(Nenhuma resposta) 


Figura 4-34 Os tipos de mensagem, de parâmetros de entrada e de valores de resposta utilizados para comunicar com o gerenciador 
de memória. 


lha, respectivamente. Cada entrada é uma estrutura que 
contém o endereço virtual, o endereço físico e o compri¬ 
mento do segmento, todos medidos em cliques em vez de 
em bytes. 0 tamanho de um clique é dependente da imple¬ 
mentação; para o MlNix-padrão é 256 bytes. Todos os seg¬ 
mentos devem iniciar em um limite de clique e ocupar um 
número integral de cliques. 

O método utilizado para registrar a alocação de me¬ 
mória é mostrado na Figura 4-35. Nessa figura, temos um 
processo com 3K de texto, 4K de dados, uma lacuna de 1K 
e, então, uma pilha de 2K, para uma alocação total de me¬ 
mória de 10K. Na Figura 4-35(b) vemos o que são os cam¬ 
pos de comprimento, físico e virtual, para cada um dos três 
segmentos, supondo que o processo não tenha espaços I e 
D separados. Nesse modelo, o segmento de texto está sem¬ 
pre vazio, e o segmento de dados contém tanto texto quan¬ 
to dados. Quando um processo referencia o endereço virtual 
0, seja para saltar para ele ou para lê-lo (i. e., como espaço 
de instrução ou como espaço de dados), o endereço físico 


0x32000 (em decimal, 200K) será utilizado. Esse endereço 
está no clique 0x320. 

Note que o endereço virtual em que a pilha começa 
depende inicialmente da quantidade total de memória alo¬ 
cada para o processo. Se o comando chmem for utilizado 
para modificar o cabeçalho do arquivo a fim de proporcio¬ 
nar uma área de alocação dinâmica maior (uma lacuna 
maior entre os segmentos de dados e de pilha), da próxima 
vez que o arquivo for executado, a pilha iniciaria em um 
endereço virtual mais alto. Se a pilha crescer mais um cli¬ 
que, a entrada da pilha deverá mudar da tripla (0x20, 
0x340, 0x8) para a tripla (1F 0x, Ox33F, 0x9). 

O hardware 8088 não tem uma interrupção de limite 
de pilha, e o MINIX define a pilha de maneira que ela não 
desencadeie a interrupção em processadores de 32 bits até 
que a pilha já tenha sobrescrito o segmento de dados. As¬ 
sim, essa alteração não será feita até a próxima chamada 
de sistema BRK, momento em que o sistema operacional 
explicitamente lê SP e recalcula as entradas de segmento. 
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r 


Endereço (hex) 


1 



21OK (0x34800) 


Pilha 

Dados 

Texto 


(0x32c00) 

Pilha 

(0x32000) 

Dados 


Texto 


(a) 


Virtual Físico Comprimento 


0x20 

0x340 

0x8 

0 

0x320 

0x1c 

0 

0x320 

0 


(b) 


Virtual Físico Comprimento 


0x14 

0x340 

0x8 

0 

0x32c 

0x10 

0 

0x320 

Oxc 


(c) 


Figura 4-35 (a) Um processo na memória, (b) Sua representação de memória para os espaços I e D 

não-separados, (c) Sua representação de memória para os espaços I e D separados. 


Em uma máquina com uma interrupção de pilha, a entra¬ 
da do segmento de pilha poderia ser atualizada logo que a 
pilha ultrapassasse seu segmento. Isso não é feito pelo MI- 
NIX em processadores Intel de 32 bits, pelas razões que ago¬ 
ra discutiremos. 

Mencionamos anteriormente que os esforços dos proje¬ 
tistas de hardware nem sempre podem produzir exatamente 
o que o projetista de software necessita. Mesmo no modo 
protegido em um Pentium, o MiNix não interrompe quan¬ 
do a pilha supera seu segmento. Embora no modo protegi¬ 
do, o hardware Intel detecte acesso à memória tentado fora 
de um segmento (como definido por um descritor de seg¬ 
mento como o da Figura 4-28), no MINIX o descritor do 
segmento de dados e o descritor do segmento de pilha são 
sempre idênticos. Os dados e a pilha definidos pelo minix 
utilizam parte desse espaço e, portanto, qualquer um ou os 
dois pode expandir-se na lacuna entre eles. Entretanto, so¬ 
mente o MINIX pode gerenciar isso. A CPU não tem como 
detectar erros que envolvem a lacuna, uma vez que, no 
que diz respeito ao hardware, a lacuna é uma parte válida 
da área de dados e da área da pilha. Naturalmente, o har¬ 
dware pode detectar um erro muito grande, tal como a ten¬ 
tativa de acessar memória a partir de fora da área combi¬ 
nada de dados, da lacuna e da pilha. Isso protegerá um 
processo de erros de outros processos, mas não é suficiente 
para proteger um processo de si mesmo. 

Uma decisão de projeto foi feita aqui. Reconhecemos 
que pode ser feito um argumento em favor do abandono 
do segmento compartilhado definido pelo hardware, o que 
permite que o minix realoque dinamicamente a área da 
lacuna. A alternativa, utilizar o hardware para definir seg¬ 
mentos de pilha e de dados que não se sobrepõem, oferece¬ 
ria alguma segurança adicional a certos erros, mas torna¬ 


ria o minix mais faminto por memória. 0 código-fonte está 
disponível para qualquer pessoa que queira avaliar a outra 
abordagem. 

A Figura 4-35(c) mostra as entradas de segmento para 
o arranjo de memória da Figura 4-35 (a) para espaços I e D 
separados. Aqui, os dois segmentos, de texto e de dados, são 
diferentes de zero no comprimento. A matriz np_seg mos¬ 
trada na Figura 4-35 (b) ou (c) é principalmente utilizada 
para mapear endereços virtuais para endereços de memó¬ 
ria físicos. Dado um endereço virtual e o espaço a que per¬ 
tence, é uma questão simples ver se o endereço virtual é 
válido ou não (i. e., cai dentro de um segmento) e, se váli¬ 
do, qual é o endereço físico correspondente. O procedimento 
de kernel umap executa esse mapeamento para as tarefas 
de E/S e para copiar para e do espaço do usuário, por exem¬ 
plo. 

0 conteúdo das áreas de dados e de pilha que pertence 
a um processo pode ser modificado enquanto o processo 
executa, mas o texto não muda. É comum para vários pro¬ 
cessos estar executando cópias do mesmo programa; por 
exemplo, vários usuários podem estar executando o mes¬ 
mo shell. A eficiência da memória é melhorada, utilizando 
texto compartilhado. Quando está para carregar um pro¬ 
cesso, exec abre o arquivo que armazena a imagem de dis¬ 
co do programa a ser carregado e lê o cabeçalho de arqui¬ 
vo. Se o processo utiliza espaços I e D separados, é feita 
uma pesquisa nos campos mp_dev, mpjno e mp_ctime 
em cada entrada de mproc. Essas armazenam os números 
de dispositivo e nó-i e o tempo/hora de alteração do status 
das imagens sendo executadas por outros processos. Se um 
processo já carregado é encontrado executando o mesmo 
programa que está para ser carregado, não há nenhuma 
necessidade de alocar memória para outra cópia do texto. 
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Em vez disso, a porção mp_seg[T\ do mapa de memória 
do novo processo é inicializada para apontar para o mes¬ 
mo lugar onde o segmento de texto já está carregado e so¬ 
mente os dados e de partes de pilha são configurados em 
uma nova alocação de memória. Isso é mostrado na Figu¬ 
ra 4-36. Se o programa utiliza espaços I e D combinados 
ou nenhuma coincidência for localizada, a memória será 
alocada como mostrado na Figura 4-35, e o texto e os da¬ 
dos para o novo processo serão copiados do disco. 

Além das informações de segmento, mproc também 
armazena o ID de processo (pid) do próprio processo e de 
seu pai, os uids e os gids (tanto reais como efetivos), as 
informações sobre sinais e o status de saída, se o processo 
já terminou, mas seu pai ainda não fez uma wait para ele. 

A outra tabela importante do gerenciador de memória 
é a tabela de lacunas, hole, definida em alloc.c, que lista 
cada lacuna na memória pela ordem ascendente do ende¬ 
reço de memória. As lacunas entre os segmentos de dados e 
de pilha não são consideradas lacunas; elas já foram alo¬ 
cadas a processos. Portanto, elas não estão contidas na lis¬ 
ta de lacunas livres. Cada entrada da lista de lacunas tem 


três campos: o endereço de base da lacuna, em cliques; o 
comprimento da lacuna, em cliques; e um ponteiro para a 
próxima entrada na lista. A lista é simplesmente encadea¬ 
da, de modo que é fácil localizar o início da próxima lacu¬ 
na a partir de qualquer dada lacuna, mas para localizar a 
lacuna anterior, você precisa pesquisar a lista inteira desde 
o início até que você chegue a uma dada lacuna. 

A razão de registrar tudo sobre segmentos e lacunas em 
cliques em vez de bytes é simples: é muito mais eficiente. 
No modo de 16 bits, inteiros de 16 bits são utilizados para 
registrar endereços de memória; portanto, com cliques de 
256 bits, até 16 MB de memória podem ser suportados. No 
modo de 32 bits, campos de endereço podem referenciar 
até 2' 10 bytes, 0 que representa 1024 gigabytes. 

As principais operações na lista de lacunas são a aloca¬ 
ção de um pedaço de memória de um tamanho dado e re¬ 
tomar uma alocação existente. Para alocar memória, a lista 
de lacunas é pesquisada, começando na lacuna com 0 en¬ 
dereço mais baixo, até que uma lacuna grande 0 suficien¬ 
te seja encontrada (primeiro ajuste). O segmento, então, é 
alocado, reduzindo-se a lacuna pela quantidade necessá- 



Virtual Físico Comprimento 


Pilha 
- Dados 
Texto 


0x14 

0x3d4 

0x8 

0 

0x3c0 

0x10 

0 

0x320 

Oxc 


Processo 2 

(c) 


(b) 


Figura 4-36 (a) O mapa de memória de um processo de espaços I e D separados, como na figura anterior, (b) O arranjo da memória 

depois que um segundo processo inicia, executando a mesma imagem do programa com texto compartilhado, (c) O mapa de memória 
do segundo processo. 
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ria para o segmento ou, no caso raro de um ajuste exato, 
removendo-se a lacuna da lista. Esse esquema é rápido e 
simples, mas padece tanto de uma pequena quantidade de 
fragmentação interna (ate' 255 bytes podem ser desperdiça¬ 
dos no clique final, uma vez que sempre é tomado um nú¬ 
mero integral de cliques) como de fragmentação externa. 

Quando um processo termina e é limpo, sua memória 
de pilha e de dados é retornada para a lista de livres. Se 
utiliza I e D comuns, isso libera toda sua memória, uma 
vez que tais programas nunca têm uma alocação separada 
de memória para texto. Se o programa utiliza I e D separa¬ 
dos, e uma consulta na tabela de processos revela que ne¬ 
nhum outro processo está compartilhando o texto, a alo¬ 
cação de texto também será retornada. Uma vez que com 
texto compartilhado as regiões de texto e de dados não são 
necessariamente contíguas, duas regiões da memória po¬ 
dem ser retornadas. Para cada região retornada, se um dos 
ou os dois vizinhos da região forem lacunas, eles são fun¬ 
didos, portanto lacunas adjacentes nunca ocorrem. Dessa 
maneira, o número, a posição e o tamanho das lacunas 
variam continuamente durante a operação do sistema. 
Sempre que todos os processos de usuário terminam, toda 
a memória disponível fica mais uma vez pronta para alo¬ 
cação. Mas isso não é necessariamente uma única lacuna, 
uma vez que a memória física pode ser interrompida por 
regiões não-utilizáveis pelo sistema operacional, como nos 
sistemas compatíveis com IBM nos quais a memória ROM 
e a memória reservada para transferências de E/S separam 
a memória usável abaixo do endereço 640K, da memória 
acima de 1M. 

4.7.4 Chamadas de Sistema FORK, 

EXIT e WAIT 

Quando processos são criados ou destruídos, a memó¬ 
ria deve ser alocada ou desalocada. Além disso, a tabela de 
processos deve ser atualizada, incluindo as partes manti¬ 
das pelo kernel e o FS. 0 gerenciador de memória coorde¬ 
na toda essa atividade. A criação de processo é feita pela 


chamada FORK e realizada na série de passos mostrada na 
Figura 4-37. 

É difícil e inconveniente parar uma chamada FORK no 
meio do caminho, assim o gerenciador de memória man¬ 
tém sempre uma contagem do número de processos atual¬ 
mente em existência para ver facilmente se uma entrada 
da tabela de processos está disponível. Se a tabela não esti¬ 
ver cheia, é feita uma tentativa de alocar memória para o 
filho. Se o programa é um programa com espaços I e D 
separados, é necessária memória suficiente apenas para 
novas alocações de dados e de pilha. Se esse passo também 
tiver sucesso, seguramente FORK funcionará. A memória 
recentemente alocada é, então, preenchida, uma entrada 
de processo é localizada e preenchida, um pid é escolhido e 
as outras partes do sistema são informadas de que um novo 
processo foi criado. 

Um processo termina completamente quando dois even¬ 
tos aconteceram juntos: (1) o próprio processo saiu (ou foi 
eliminado por um sinal) e (2) seu pai executou uma cha¬ 
mada de sistema wait para saber o que aconteceu. Um pro¬ 
cesso que saiu ou foi eliminado, mas cujo pai não fez (ain¬ 
da) uma wait para ele, entra em um tipo de animação sus¬ 
pensa, às vezes, conhecido como estado zumbi. Ele é im¬ 
pedido de ser agendado e tem seu temporizador de alarme 
desligado (se estiver ligado), mas não é removido da tabe¬ 
la de processos. Sua memória é liberada. 0 estado zumbi é 
temporário e raramente dura muito. Quando o pai, por fim, 
faz a WAIT, a entrada da tabela de processos é liberada e o 
sistema de arquivos e o kernel são informados. 

Um problema surge se o próprio pai de um processo 
que está saindo já estiver morto. Se nenhuma ação especi¬ 
al for tomada, o processo que está saindo permaneceria 
um zumbi eternamente. Em vez disso, as tabelas são alte¬ 
radas para torná-lo um filho do processo init. Quando o 
sistema surge, init lê o axt\u\\’o /etc/ttytab para obter uma 
lista de todos os terminais e, então, cria um processo de 
login para tratar cada uma. Então, ele bloqueia, esperan¬ 
do os processos terminarem. Dessa maneira, órfãos zum¬ 
bis são removidos rapidamente. 


1. Verificar se a tabela de processos está cheia. 

2. Tentar alocar memória para os dados e para a pilha do filho. 

3. Copiar os dados e a pilha do pai para a memória do filho. 

4. Localizar uma entrada de processo livre e copiá-la do pai para ele. 

5. Inserir o mapa de memória do filho na tabela de processos. 

6. Escolher um pid para o filho. 

7. Informar o kernel e o sistema de arquivos sobre filho, 

8. Informar o mapa de memória do filho para o kernel. 

9. Enviar mensagens de resposta para pai e para filho 


Figura 4-37 Os passos exigidos para executar a chamada de sistema FORK. 
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4.7.5 Chamada de Sistema EXEC 

Quando um comando é digitado no terminal, o shell 
cria um novo processo, que, então, executa o comando so¬ 
licitado. Teria sido possível ter uma única chamada de sis¬ 
tema fazendo ambas, fork e exec de uma vez, mas elas 
foram oferecidas como duas chamadas distintas por uma 
razão muito boa: facilitar a implementação de redirecio- 
namento de E/S. Quando o shell cria um filho, se a entra- 
da-padrão estiver redirecionada, o filho fecha a entrada- 
padrão e, então, abre a nova entrada-padrão antes de exe¬ 
cutar o comando. Dessa maneira, o processo recentemente 
iniciado herda a entrada-padrão redirecionada. A saída- 
padrão é tratada da mesma maneira. 

EXEC é a chamada de sistema mais complexa no MINTX. 
Ela deve substituir a imagem atual da memória por uma 
nova, incluindo configurar uma nova pilha. Ela realiza 
seu trabalho em uma série de passos, como mostrado na 
Figura 4-38. 

Cada passo consiste, por sua vez, de outros ainda me¬ 
nores, alguns dos quais podem falhar. Por exemplo, pode 
não haver memória suficiente. A ordem em que os testes 
são feitos foi cuidadosamente escolhida para certificar-se 
de que a imagem da memória antiga não foi liberada até 
que seja certo que o EXEC terá sucesso, para evitar a situa¬ 
ção embaraçosa de não ser capaz de configurar uma nova 
imagem da memória, e também não ter a antiga para res¬ 
taurar. Normalmente EXEC não retorna, mas se falhar, o 
processo de chamada deve obter o controle novamente, com 
uma indicação do erro. 

Há alguns passos na Figura 4-38 que merecem mais 
comentários. Primeiro é a pergunta de se há ou não espaço 
suficiente. Depois de determinar quanta memória é neces¬ 
sária, o que exige determinar se a memória de texto de 
outro processo pode ser compartilhada, a lista de lacunas 
inteira é pesquisada para verificar se há memória física 
suficiente antes de liberar a memória antiga — se a me¬ 
mória antiga fosse liberada primeiro e houvesse memória 
insuficiente, seria difícil obter de volta a imagem antiga 
novamente. 


Entretanto, esse teste é excessivamente estrito. Ele, às 
vezes, rejeita chamadas EXEC que. de fato, poderiam ter su¬ 
cesso. Suponha, por exemplo, que o processo que faz a cha¬ 
mada EXEC ocupe 20K e seu texto não seja compartilhado 
por qualquer outro processo. Suponha ainda que haja urna 
lacuna de 30K disponível e que a nova imagem exija 50K. 
Testando antes de liberar, descobriremos que somente 30K 
estão disponíveis e rejeitaremos a chamada. Se tivéssemos 
liberado primeiro, talvez pudéssemos ter sucesso, depen¬ 
dendo de a nova lacuna de 20K ser ou não adjacente, por¬ 
tanto agora fundida com a lacuna de 30K. Uma imple¬ 
mentação mais sofisticada poderia tratar essa situação um 
pouco melhor. 

Outro possível aprimoramento seria pesquisar duas la¬ 
cunas, uma para o segmento de texto e uma para o seg¬ 
mento de dados, se o processo a ser EXECutado utilizasse 
espaços I e D separados. Não há nenhuma necessidade de 
os segmentos serem contíguos. 

Uma questão mais sutil é o arquivo executável ajustar- 
se no espaço de endereço virtual. 0 problema é que a me¬ 
mória não é alocada em bytes, mas em cliques de 256 bytes. 
Cada clique deve pertencer a um único segmento e não 
pode ser, por exemplo, metade dados, metade pilha, por¬ 
que a administração inteira da memória está em cliques. 

Para ver como essa restrição pode causar problemas, 
note que o espaço de endereço em sistemas de 16 bits (8088 
e 80286) é limitado a 64K, o que pode ser dividido em 256 
cliques. Suponha que um programa de espaços I e D sepa¬ 
rados tenha 40.000 bytes de texto, 32.770 bytes de dados e 
32.760 bytes de pilha. O segmento de dados ocupa 129 cli¬ 
ques, dos quais 0 último é apenas parcialmente utilizado; 
entretanto, 0 clique inteiro é parte do segmento de dados. 
O segmento da pilha é 128 cliques. Juntos, eles excedem 
256 cliques e, portanto, não podem coexistir, mesmo que 0 
número de bytes necessários (mal) se ajuste no espaço de 
endereço virtual. Na teoria, esse problema existe em todas 
as máquinas cujo tamanho do clique é maior que 1 byte, 
mas, na prática, raramente ocorre em processadores da clas¬ 
se Pentium, uma vez que esses permitem grandes segmen¬ 
tos (4 GB). 


1. Verificar permissões — o arquivo é executável? 

2. Ler o cabeçalho para obter os tamanhos dos segmentos e 0 tamanho total. 

3. Buscar os argumentos e 0 ambiente do chamador. 

4. Alocar nova memória e liberar memória antiga não-necessária. 

5. Copiar a pilha para a nova imagem da memória. 

6. Copiar 0 segmento de dados (e possivelmente de texto) para a nova imagem da memória. 

7. Verificar e tratar os bits setuid, setgid. 

8. Corrigir entradas da tabela de processos. 

9. Informar 0 kernel que o processo agora é executável. 


Figura 4-38 Os passos exigidos para executar a chamada de sistema exec. 
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Outra questão importante é como a pilha inicial é con¬ 
figurada. A chamada de biblioteca normalmente utilizada 
para invocar EXEC com argumentos e com um ambiente é 

execvefname, argv, envp); 

onde name é um ponteiro para o nome do arquivo a ser 
executado, argv é um ponteiro para uma matriz de pon¬ 
teiros, cada um apontando para um argumento, e envp é 
um ponteiro para uma matriz de ponteiros, cada um apon¬ 
tando para uma string do ambiente. 

Seria muito fácil implementar EXEC colocando simples¬ 
mente os três ponteiros na mensagem para o gerenciador 
de memória e deixá-lo buscar o nome do arquivo e as duas 
matrizes sozinhas. Então, ele teria de buscar cada argu¬ 
mento e cada string uma por vez. Fazer isso dessa maneira 
exige pelo menos uma mensagem à tarefa de sistema por 
argumento ou por string, e provavelmente mais, uma vez 
que o gerenciador de memória não tem como saber o ta¬ 
manho de cada um de antemão. 

Para evitar o overhead de múltiplas mensagens lendo 
todos esses pedaços, uma estratégia completamente dife¬ 
rente foi escolhida. 0 procedimento de biblioteca execve 
constrói a pilha inicial inteira dentro de si mesmo e passa 
seu endereço de base e seu tamanho para o gerenciador de 
memória. Criar a nova pilha dentro do espaço usuário é 


bastante eficiente, porque as referências a argumentos e a 
strings são referências de memória locais, não referências 
a um espaço de endereço diferente. 

Para tornar esse mecanismo mais claro, considere um 
exemplo. Quando um usuário digita 

Is -I f.c g.c 

para o shell, o shell interpreta-o e, então, faz a chamada 
execve(“/bin/ls”, argv, envp); 

para o procedimento de biblioteca. 0 conteúdo das duas 
matrizes de ponteiros é mostrado na Figura 4-39 (a). O pro¬ 
cedimento execve, dentro do espaço de endereço do shell, 
agora constrói a pilha inicial, como mostrado na Figura 4- 
39 (b). Essa pilha por fim é copiada intacta para o gerenci¬ 
ador de memória durante o processamento da chamada 
EXEC. 

Quando a pilha por fim é copiada para o processo do 
usuário, ela não será colocada no endereço virtual 0. Em 
vez disso, ela será colocada no fim da memória alocada, 
como determinado pelo campo total de tamanho de me¬ 
mória no cabeçalho do arquivo executável. Como um exem¬ 
plo, vamos arbitrariamente supor que o tamanho total é 
8192 bytes, então, o último byte disponível para o progra¬ 
ma está no endereço 8191- Cabe ao gerenciador de memó- 
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Figura 4-39 (a) As matrizes passadas a execve. (b) A pilha construída por execve. (c) Apilhaapósarealocação 

pelo gerenciador de memória, (d) A pilha como aparece para main no início da execução. 
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ria realocar os ponteiros dentro da pilha de modo que quan¬ 
do depositado no novo endereço a pilha fique parecida com 
a Figura 4-39(c) 

Quando a chamada EXEC é concluída, e o programa 
começa a executar, a pilha, de fato, ficará exatamente como 
na Figura 4-39(c), com o ponteiro da pilha tendo o valor 
8136. Entretanto, outro problema ainda precisa ser resol¬ 
vido. O programa principal do arquivo executado prova¬ 
velmente declarou algo assim: 

main(argc, argv, envp); 

no que diz respeito ao compilador de C, main é somente 
outra função. Não sabe que main é especial, então, com¬ 
pila 0 código para acessar os três parâmetros na suposição 
de que eles serão passados de acordo com a convenção- 
padrão de chamada de C, último parâmetro primeiro. Com 
um inteiro e dois ponteiros, espera-se os três parâmetros 
ocuparem as três palavras exatamente antes do endereço 
de retorno. Naturalmente, a pilha da Figura 4-39(c) não 
se parece com isso de modo algum. 

A solução é fazer com que os programas não comecem 
com main. Em vez disso, uma pequena rotina de lingua¬ 
gem assembly, crtso , o procedimento start-off de tempo de 
execução do C, sempre é vinculada no endereço 0 do texto 
para que obtenha controle primeiro. Seu trabalho é em¬ 
purrar mais três palavras sobre a pilha e, então, chamar 
main, utilizando a instrução-padrão de chamada. Isso re¬ 
sulta na pilha da Figura 4-39(d) no momento em que main 
começa a executar. Assim, main é enganada, pensando que 
foi chamada da maneira normal (na realidade, não é um 
truque de verdade; ela é chamada dessa maneira). 

Se o programador omite a chamada a exit no fim de 
main, o controle passará de volta para a rotina destart-off 
quando main termina. Novamente, o compilador apenas 
vê main como um procedimento comum e gera o código 
normal para retornar dele depois da última declaração. 
Assim, main retoma para seu chamador, a rotina destart- 
off que, então, chama exit. A maior parte do código de 32 
bits de crtso é mostrada na Figura 4-40. Os comentários 
devem esclarecer sua operação. Tudo que foi deixado de 
fora é o código que carrega os registradores que são colo¬ 
cados na pilha, e algumas linhas que configuram um si¬ 
nalizador, indicando se um co-processador de ponto flutu¬ 
ante está presente ou não. 


4.7.6 Chamada de Sistema de BRK 

Os procedimentos de biblioteca brk e sbrk são utiliza¬ 
dos para ajustar o limite superior do segmento de dados. O 
primeiro toma um tamanho absoluto (em bytes) e chama 
BRK. O último toma um incremento positivo ou negativo 
para o tamanho atual, calcula o novo tamanho de seg¬ 
mento de dados e, então, chama BRK. Não há uma chama¬ 
da de sistema sbrk real. 

Uma pergunta interessante é: “Como sbrk monitora o 
tamanho atual, de modo que possa calcular o novo tama¬ 
nho?” A resposta é que uma variável, brksize, sempre ar¬ 
mazena o tamanho atual de modo que sbrk possa locali- 
zá-lo. Essa variável é inicializada para um símbolo gerado 
pelo compilador que fornece o tamanho inicial de texto 
mais dados (I e D não-separados) ou dados apenas (1 e D 
separados). O nome e, de fato, a própria existência desse 
símbolo depende do compilador e, portanto, ele não será 
encontrado definido em qualquer arquivo de cabeçalho nos 
diretórios dos arquivos-fonte. Ele é definido na biblioteca, 
no arquivo brksize.s. O lugar exato onde ele estará locali¬ 
zado depende do sistema, mas ele estará no mesmo dire¬ 
tório que crtso.s. 

Executar BRK é fácil para o gerenciador de memória. 
Tudo que deve ser feito é verificar se tudo ainda cabe no 
espaço de endereço, ajustar as tabelas e informar o kernel. 

4.7.7 Manipulação de Sinais 

No Capítulo 1, os sinais foram descritos como um me¬ 
canismo para transportar as informações para um proces¬ 
so que não necessariamente está esperando entrada. Há um 
conjunto definido de sinais e cada um deles tem uma ação- 
padrão — seja eliminar um processo para o qual é dirigi¬ 
do, seja ignorar o sinal. O processamento de sinais seria 
fácil de entender e de implementar se estas fossem as úni¬ 
cas alternativas. Entretanto, processos podem utilizar cha¬ 
madas de sistema que alteram essas respostas. Um proces¬ 
so pode solicitar que qualquer sinal (exceto para o sinal 
especial SIGKILL) seja ignorado. Ademais, um processo pode 
preparar para capturar um sinal, solicitando que um pro¬ 
cedimento de manipulação de sinal interno ao processo 
seja ativado em vez da ação padrão para qualquer sinal 
(exceto, novamente, para SIGKILL). Portanto, ao progra- 
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Figura 4-40 A parte-chave da rotina start-off de tempo de execução do C. 
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mador aparece que há dois tempos distintos quando o sis¬ 
tema operacional lida com sinais: uma fase de preparação 
quando um processo pode modificar sua resposta para um 
sinal futuro, e para uma fase de resposta quando um sinal é 
gerado e sofre uma ação. A ação pode ser a execução de um 
manipulador de sinais personalizado. Na verdade, há uma 
terceira fase. Quando um manipulador escrito pelo usuário 
termina, uma chamada de sistema especial limpa e restau¬ 
ra a operação normal do processo sinalizado. 0 programa¬ 
dor não precisa tomar conhecimento sobre essa terceira fase. 
Ele escreve um manipulador de sinal como qualquer outra 
função. 0 sistema operacional cuida dos detalhes de invo¬ 
car e de terminar o manipulador e de gerenciar a pilha. 

Na fase de preparação, há várias chamadas de sistema 
que um processo pode executar em qualquer momento para 
alterar sua resposta para um sinal. A mais geral dessas é 
SIGACTION, que pode especificar que o processo ignore al¬ 
guns sinais, capture algum sinal (substituindo a ação-pa¬ 
drão pela execução de um código de tratamento de sinal 
definido pelo usuário dentro do processo) ou restaure a res¬ 
posta-padrão para algum sinal. Outra chamada de siste¬ 
ma, SIGPROCMASK, pode bloquear um sinal, fazendo com 
que ele seja enfileirado e seja executado somente quando e 
se o processo desbloquear aquele sinal particular em um 
momento mais tarde. Essas chamadas podem ser feitas a 
qualquer momento, mesmo dentro de uma função de cap¬ 
tura de sinal. No MINIX, a fase de preparação de processa¬ 
mento de sinal é tratada inteiramente pelo gerenciador de 
memória, uma vez que as estruturas de dados necessárias 
estão todas na parte do gerenciador de memória da tabela 
de processos. Para cada processo, há diversas variáveis 
sigsetj, nas quais cada possível sinal é representado por 
um bit. Uma variável desse tipo define um conjunto de si¬ 
nais que devem ser ignorados, outra define um conjunto 
que deve ser capturado e assim por diante. Para cada pro¬ 
cesso, também há uma matriz de estruturas sigaction , uma 
para cada sinal. Cada elemento da estrutura sigaction con¬ 
tém uma variável para armazenar o endereço de um ma¬ 
nipulador personalizado para esse sinal, e uma variável 
sigsetj adicional para mapear sinais a serem bloqueados 
enquanto aquele manipulador está executando. O campo 
utilizado para o endereço do manipulador pode, em vez 
disso, armazenar valores especiais que significam que o 
sinal deve ser ignorado ou deve ser tratado na maneira pa¬ 
drão definida para esse sinal. 

Quando um sinal é gerado, múltiplas partes do sistema 
MINIX podem ser envolvidas. A resposta começa no gerenci¬ 
ador de memória, o qual descobre quais processos devem 
obter o sinal, utilizando as estruturas de dados recém-men- 
cionadas. Se o sinal deve ser capturado, ele deve ser entre¬ 
gue para o processo de destino. Isso requer salvar as infor¬ 
mações sobre o estado do processo, de tal modo que a exe¬ 
cução normal possa ser reassumida. As informações são 
armazenadas na pilha do processo sinalizado, e uma veri¬ 
ficação deve ser feita para determinar se há espaço de pilha 
suficiente. 0 gerenciador de memória faz essa verificação, 
uma vez que isso está dentro do seu âmbito e, então, cha¬ 


ma a tarefa de sistema no kernel para colocar as informa¬ 
ções na pilha. A tarefa de sistema também manipula o con¬ 
tador de programa do processo, então o processo pode exe¬ 
cutar o código do manipulador. Quando o manipulador 
termina, uma chamada de sistema SIGRETURN é feita. Por 
essa chamada, tanto o gerenciador de memória como o 
kernel participam da restauração do contexto e dos regis¬ 
tradores do processo para que a execução normal possa ser 
reassumida. Se o sinal não for capturado, a ação-padrão é 
tomada, o que pode envolver chamar o sistema de arquivos 
para produzir um dutnp de núcleo (gravando a imagem 
do processo em um arquivo que pode ser examinado com 
um depurador), assim como eliminar o processo, o que en¬ 
volve o sistema de arquivos, o gerenciador de memória e o 
kernel. Por fim, o gerenciador de memória pode dirigir uma 
ou mais repetições dessa ação, uma vez que um único sinal 
pode precisar ser entregue para um grupo de processos. 

Os sinais conhecidos para o minix são definidos em / 
usr/indude/signal.h , um arquivo exigido pelo padrão P0- 
SIX. Eles são listados na Figura 4-41. Todos os sinais exigi¬ 
dos pelo posix são definidos no minix, mas nem todos eles 
são atualmente suportados. Por exemplo, o POSIX exige 
vários sinais relacionados com controle de jobs, com a ca¬ 
pacidade de colocar em segundo plano um programa em 
execução e de trazê-lo de volta. 0 MINIX não suporta con¬ 
trole de jobs. mas programas que talvez gerem esses sinais 
podem ser portados para o MINIX. Se gerados, tais sinais 
serão ignorados. 0 MINIX também define alguns sinais não- 
POSIX e alguns sinônimos para nomes POSIX para compati¬ 
bilidade com código-fonte mais antigo. 

Os sinais podem ser gerados de duas maneiras: pela 
chamada de sistema KILL e pelo kernel. Os sinais gerados 
pelo kernel do minix sempre incluem sigint, sigquit e Si- 
galrm. Outros sinais do kernel dependem de suporte de 
hardware. Por exemplo, os processadores 8086 e 8088 não 
suportam detecção de códigos ilegais de operação de ins¬ 
trução, mas essa capacidade está disponível nos 286 e nos 
superiores, que interrompem uma tentativa de executar um 
opcode ilegal. Esse serviço é oferecido pelo hardware. O 
implementador do sistema operacional deve oferecer códi¬ 
go para gerar um sinal em resposta à interrupção. Vimos, 
no Capítulo 2, que kernel/exception.c contém código para 
fazer exatamente isso para diversas condições diferentes. 
Assim, um sinal SIGILL pode ser gerado em resposta a uma 
instrução ilegal quando o minix executa em processador 
286 ou superior, mas esse sinal nunca será visto quando o 
minix executar em um 8088. 

Apenas porque o hardware pode gerar uma interrupção 
em uma certa condição, não significa que essa capacidade 
possa ser utilizada completamente pelo implementador do 
sistema operacional. Por exemplo, vários tipos de violações 
de integridade de memória resultam em exceções em todos 
os processadores Intel, começando com os 286. 0 código 
em kernel/exception.c traduz essas exceções em sinais SIG- 
segy. Há exceções separadas geradas para infrações dos li¬ 
mites do segmento de pilha definido pelo hardware e para 
outros segmentos, uma vez que estes talvez precisam ser 
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Sinal 

Descrição 

Gerado por 

SIGHUP 

Desconecta ( hangup) 

Chamada de sistema KILL 

SIGINT 

Interrupção 

Kernel 

SIGQUIT 

Encerrar 

Kernel 

SIGILL 

Instrução ilegal 

Kernel (*) 

SIGTRAP 

Interrupção de depuração 

Kernel (M) 

SIGABRT 

Terminação anormal 

Kernel 

SIGFPE 

Exceção de ponto flutuante 

Kernel (*) 

SIGKILL 

Eliminar (não pode ser capturado nem pode ser ignorado) 

Chamada de sistema KILL 

SIGUSR1 

Sinal definido pelo usuário 1 

Não suportado 

SIGSEGV 

Violação de segmentação 

Kernel (*) 

SIGUSR2 

Sinal definido pelo usuário 2 

Não suportado 

SIGPIPE 

Gravação em um pipe sem ninguém para lê-lo 

Kernel 

SIGALRM 

Alarme do relógio, tempo limite 

Kernel 

SIGTERM 

Sinal de software para encerramento proveniente de kill 

Chamada de sistema KILL 

SIGCHLD 

Processo-filho terminado ou parado 

Não-suportado 

SIGCONT 

Continua se parado 

Não-suportado 

SIGSTOP 

Sinal de parada 

Não-suportado 

SIGTSTP 

Sinal de parada interativo 

Não-suportado 

SIGTTIN 

Processo em segundo plano quer ler 

Não-suportado 

SIGTTOU 

Processo em segundo plano quer escrever 

Não-suportado 


Figura 4-41 ^ Sinais definidos pelo posix e pelo minix. Sinais indicados por (*) dependem de suporte de hardware. Sinais marcados 
com (M) não são definidos pelo posix, mas o são pelo minix para compatibilidade com programas mais antigos. Vários nomes obsoletos 
e sinônimos não estão listados aqui. 


tratados de maneira diferente. Entretanto, por causa da 
maneira como o minix utiliza a memória, o hardware não 
pode detectar todos os erros que talvez ocorram. 0 hardwa¬ 
re define uma base e um limite para cada segmento. A base 
do segmento de dados definida pelo hardware é a mesma 
que a base do segmento de dados do minix, mas o limite 
definido pelo hardware do segmento de dados é mais alto 
do que o limite que o minix impõe em software. Em outras 
palavras, o hardware define o segmento de dados como a 
maior quantidade de memória que o minix possivelmente 
poderia utilizar para dados, se por alguma razão a pilha 
reduzir-se a nada. De maneira similar, o hardware define a 
pilha como a quantidade máxima de memória que a pilha 
do minix poderia utilizar se a área de dados pudesse redu¬ 
zir-se a nada. Embora certas infrações possam ser detecta¬ 
das pelo hardware, este não pode detectar a infração mais 
provável de pilha, o crescimento da pilha na área de dados, 
uma vez que no que diz respeito aos registradores de hard¬ 
ware e às tabelas de descritores a área de dados e a área da 
pilha sobrepõem-se. 

Concebivelmente algum código poderia ser adicionado 
ao kernel, que verificaria os registradores de cada processo 
depois de cada vez que o processo obtivesse uma chance de 


executar e geraria um sinal SIGSEGV ao detectar uma infra¬ 
ção da integridade das áreas de dados e de pilha definidas 
no minix. O benefício de fazer isso é incerto; as interrup¬ 
ções de hardware podem capturar uma violação imediata¬ 
mente. Uma verificação de software poderia não ter uma 
chance de fazer seu trabalho ate' que muitas milhares de 
instruções adicionais tivessem sido executadas e, nesse pon¬ 
to, talvez haja muito pouco que um manipulador de sinal 
possa fazer para tentar recuperar. 

Qualquer que seja sua a origem, o gerenciador de me¬ 
mória processa todos os sinais da mesma maneira. Para 
cada processo a ser sinalizado, diversas verificações são fei¬ 
tas para ver se o sinal é praticável. Um processo pode sina¬ 
lizar outro se o sinalizador é o superusuário ou se o uid 
real ou efetivo do sinalizador é igual ao uid real ou efetivo 
do processo sinalizado. Mas há várias condições que po¬ 
dem impedir que um sinal seja enviado. Zumbis não po¬ 
dem ser sinalizados, por exemplo. Um processo não pode 
ser sinalizado se ele tiver explicitamente chamado SIGAC- 
tion para ignorar o sinal ou sigprocmask para bloqueá- 
lo. Bloquear um sinal é diferente de ignorá-lo; a recepção 
de um sinal bloqueado é memorizada e é entregue quando 
e se o processo sinalizado remover o bloqueio. Por fim, se 
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seu espaço de pilha não for adequado, o processo sinaliza¬ 
do é eliminado. 

Se todas as condições são satisfeitas, o sinal pode ser 
enviado. Se o processo não arranjou para o sinal ser captu¬ 
rado, nenhuma informação precisa ser passada para o pro¬ 
cesso. Nesse caso o gerenciador de memória executa a ação- 
padrão para o sinal, que é normalmente eliminar o pro¬ 
cesso, possivelmente produzindo também um dump de 
núcleo. Para alguns sinais, a ação-padrão é ignorar o si¬ 
nal. 0 POSix exige que os sinais marcados como “Não-su- 
portado" na Figura 4-41 sejam definidos, mas eles são ig¬ 
norados pelo MIMX. 

Capturar um sinal significa executar o código persona¬ 
lizado de tratamento de sinal do processo, cujo endereço é 
armazenado em uma estrutura sigaction na tabela de pro¬ 
cessos. No Capítulo 2, vimos como a moldura de pilha de 
um processo dentro de sua entrada na tabela de processos 
recebe as informações necessárias para reiniciar o proces¬ 
so quando ele é interrompido. Modificando-se a moldura 
de pilha de um processo a ser sinalizado, pode-se arranjar 
as coisas para que, quando o processo em seguida tenha 
permissão para executar, o manipulador de sinal execute. 
Modificando a própria pilha do processo no espaço do usu¬ 
ário, pode-se arranjar as coisas para que, quando o mani¬ 
pulador de sinal termine, a chamada de sistema SIGRETURN 
seja feita. Essa chamada de sistema nunca é invocada por 
código escrito pelo usuário, ela é executada depois que o 
kmiel coloca seu endereço na pilha de tal maneira que 
seu endereço torna-se o endereço de retorno retirado da 
pilha, quando um manipulador de sinal termina. SIGRE- 
TURX restaura a moldura de pilha original do processo si¬ 
nalizado, para que ele possa reassumir a execução no pon¬ 
to onde foi interrompido pelo sinal. 

Embora a etapa final de enviar um sinal seja feita pela 
a tarefa de sistema, esse é um bom lugar para resumir-se 
como ela é feita, uma vez que os dados utilizados são pas¬ 
sados para o kernel pelo gerenciador de memória. Captu¬ 
rar um sinal requer algo muito parecido com a comutação 
de contexto que ocorre quando um processo é tirado da 
execução e outro processo é colocado em execução, uma 
vez que quando o manipulador conclui, o processo deve 
ser capaz de continuar como se nada tivesse acontecido. 
Entretanto, há somente um lugar na tabela de processos 
para armazenar o conteúdo de todos os registradores da 
CPU que são necessários para restaurar o processo ao seu 
estado original. A solução para esse problema é mostrada 
na Figura 4-42. A parte (a) da figura é uma visão simplifi¬ 
cada da pilha de um processo e parte de sua entrada na 
tabela de processos logo depois que ele foi tirado da execu¬ 
ção após uma interrupção. No momento da suspensão, o 
conteúdo de todos os registradores da CPU é copiado para a 
estrutura da moldura de pilha na entrada da tabela de pro¬ 
cessos desse processo, na parte do kernel da tabela de pro¬ 
cessos. Essa será a situação no momento em que um sinal 
for gerado, uma vez que um sinal é gerado por um proces¬ 
so ou por uma tarefa diferente do destinatário pretendido. 


Na preparação da manipulação dos sinais, a moldura 
de pilha da tabela de processos é copiada para a própria 
pilha do processo como uma estrutura sigcontext, assim 
preservando-a. Então, uma estrutura sigframe é colocada 
na pilha. Essa estrutura contém as informações a serem 
utilizadas por siGRETURX depois que o manipulador é con¬ 
cluído. Ela também contém o endereço do procedimento 
de biblioteca que invoca a própria SIGRF,turn, ret addrl e 
outros endereços de retorno, ret addr2, que é o endereço 
onde a execução do programa interrompido será reassu¬ 
mida. Como será visto, entretanto, o último endereço não 
é utilizado durante a execução normal. 

Embora o manipulador seja escrito como um procedi¬ 
mento costumeiro pelo programador, ele não é chamado 
por uma instrução de chamada. O campo do ponteiro de 
instrução (contador de programa) na moldura de pilha na 
tabela de processos é alterado para fazer o manipulador de 
sinal começar a executar quando restart coloca o processo 
sinalizado de volta em execução. A Figura 4-42 (b) mostra 
a situação depois que essa preparação foi completada e 
como o manipulador de sinal executa. Lembre-se de que o 
manipulador de sinal é um procedimento usual, então, 
quando ele termina, ret addrl é retirado da pilha e SIGRE- 
TURN executa. 

A parte (c) mostra a situação enquanto SIGRETURX está 
executando. O restante da estrutura sigframe são agora 
variáveis locais de SIGRETURN. Parte da ação de sigreturn 
é ajustar seu próprio ponteiro de pilha de tal modo que se 
ela fosse uma função para terminar como uma função co¬ 
mum, ela utilizaria ret addr2 como seu endereço de retor¬ 
no. Entretanto, SIGRETURX realmente não termina dessa 
maneira. Ela termina como outras chamadas de sistema, 
permitindo que o agendador no kernel decida qual proces¬ 
so reiniciar. Por fim, o processo sinalizado será reagenda- 
do e reiniciará nesse endereço, porque o endereço também 
está na moldura de pilha do processo original. A razão pela 
qual esse endereço está na pilha é que o usuário talvez quei¬ 
ra rastrear um programa, utilizando um depurador e isso 
engana o depurador, fazendo-o ter uma interpretação ra¬ 
zoável da pilha, enquanto um manipulador de sinal está 
sendo rastreado. Em cada fase, a pilha parece-se com a de 
um processo comum, com variáveis locais sobre um ende¬ 
reço de retorno. 

0 trabalho real de sigreturn é restaurar as coisas para 
o estado em que elas estavam antes de o sinal ter sido rece¬ 
bido, além da limpeza. Sobretudo, a moldura de pilha na 
tabela de processos é restaurada ao seu estado original, uti¬ 
lizando a cópia que foi salva na pilha do processo sinaliza¬ 
do. Quando sigreturn termina, a situação será como a da 
Figura 4-42(d), que mostra o processo que espera, voltan¬ 
do à execução no mesmo estado em que estava quando foi 
interrompido. 

Para a maioria dos sinais, a ação-padrão é eliminar o 
processo sinalizado. 0 gerenciador de memória cuida dis¬ 
so para qualquer sinal que não seja ignorado por padrão e 
cujo processo destinatário não foi habilitado para tratar, 
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Figura 4-42 Uma pilha de processo (acima) e sua moldura de pilha na tabela de processos (embaixo), correspondendo a fases no 
tratamento de um sinal, (a) Estado enquanto o processo é tirado de execução, (b) Estado quando o manipulador começa a executar, (c) 
Estado quando sigreturn está executando, (d) Estado depois que sigreturn completa a execução. 


bloquear ou para ignorar. Se o pai está esperando-o, o pro¬ 
cesso eliminado é limpo e removido da tabela de processos. 
Se o pai não o está esperando, ele se torna um zumbi. Para 
certos sinais (p. ex., SIGQUIT), o gerenciador de memória 
também grava um dump de núcleo do processo no dire¬ 
tório atual. 

Facilmente pode acontecer de um sinal ser enviado para 
um processo que atualmente está bloqueado, esperando por 
um READ em um terminal para o qual nenhuma entrada 
está disponível. Se o processo não especificou que o sinal 
deve ser capturado, ele é simplesmente eliminado da ma¬ 
neira normal. Se, entretanto, o sinal é para ser capturado, 
surge a questão sobre o que fazer depois que a interrupção 
de sinal foi processada. 0 processo deve voltar ao estado de 
espera ou deve continuar com a próxima declaração? 

0 que o MINIX faz é isto: a chamada de sistema é termi¬ 
nada de tal maneira que ela retorna o código de erro EÍN- 
TR para que o processo possa ver que a chamada foi inter¬ 
rompida por um sinal. Determinar se um processo sinali¬ 
zado foi bloqueado em uma chamada de sistema não é 


inteiramente trivial. 0 gerenciador de memória deve soli¬ 
citar que o sistema de arquivos verifique por ele. 

Esse comportamento é sugerido, mas não é exigido, pelo 
POSIX, que também permite que um READ retorne o núme¬ 
ro de bytes lidos até o momento da recepção do sinal. Re¬ 
tornar EINTR toma possível configurar um alarme e cap¬ 
turar SIGALRM. Essa é uma maneira fácil de implementar 
um limite de tempo, por exemplo, terminando login e des¬ 
ligando uma linha de modem se um usuário não respon¬ 
der dentro de um certo período de tempo. A tarefa de reló¬ 
gio síncrono pode ser utilizada para fazer a mesma coisa 
com menor overhead, mas é uma invenção do MINIX e não 
tão portável quanto a utilização de sinais. Além disso, está 
disponível somente para processos de servidor e não para 
processos de usuário comuns. 

4.7.8 Outras Chamadas de Sistema 

0 gerenciador de memória trata algumas chamadas de 
sistema mais simples. As funções de biblioteca getuidege- 
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teuid invocam a chamada de sistema getuid, que retorna 
os dois valores em sua mensagem de retorno. De maneira 
semelhante, a chamada de sistema GETGID também retor¬ 
na valores efetivos reais para serem utilizados pelas fun¬ 
ções getgid e getegid. GETPID funciona da mesma maneira 
para retornar o ID do processo; e o 1D do processo do pai, e 
SETUID e SETGID podem configurar os valores tanto reais 
como efetivos em uma chamada. Há duas chamadas de 
sistema adicionais nesse grupo, GETPGRP e SETSID. A pri¬ 
meira retorna o ID de grupo do processo, e a última confi¬ 
gura-o como o valor do pid atual. Essas sete são as chama¬ 
das de sistema mais simples do minix. 

As chamadas de sistema ptrace e REBOOT também são 
tratadas pelo gerenciador de memória. A primeira suporta 
depuração de programas. A última afeta muitos aspectos 
do sistema. Ela é apropriada para ser colocada no gerenci¬ 
ador de memória porque sua primeira ação é enviar sinais 
para eliminar todos os processos, exceto init. Depois disso, 
ela chama o sistema de arquivos e a tarefa de sistema para 
completarem seu trabalho. 

4.8 IMPLEMENTAÇÃO DO 
GERENCIAMENTO DE MEMÓRIA NO 
MINEX 

Munidos de uma visão geral de como o gerenciador de 
memória funciona, voltemos agora a examinar o código 
em si. 0 gerenciador de memória é escrito inteiramente 
em C, sendo simples e direto e contém uma quantidade 
substancial de comentários no próprio código, de modo que 
nossa abordagem da maioria das partes não precisa ser lon¬ 
ga ou complicada. Veremos primeiro um resumo dos ar¬ 
quivos de cabeçalho, depois o programa principal e, por 
fim, os arquivos para os vários grupos de chamadas de sis¬ 
tema discutidos anteriormente. 

4.8.1 Arquivos de Cabeçalho e 
Estruturas de Dados 

Vários arquivos de cabeçalho no diretório de fontes do 
gerenciador de memória têm os mesmos nomes que os ar¬ 
quivos no diretório do kernel, e esses nomes serão vistos 
novamente no sistema de arquivos. Tais arquivos têm fun¬ 
ções semelhantes nos seus respectivos contextos. A estrutu¬ 
ra paralela é projetada para facilitar o entendimento da 
organização global do sistema MINIX. 0 gerenciador de 
memória também tem diversos cabeçalhos com nomes 
únicos. Como em outras partes do sistema, o armazena¬ 
mento para variáveis globais é reservado para quando é 
compilada a versão de table.c do gerenciador de memória. 
Nesta seção, veremos todos os arquivos de cabeçalho, as¬ 
sim como table.c. 

Como com outras partes importantes do MINIX, o ge¬ 
renciador de memória tem um arquivo de cabeçalho prin¬ 
cipal, o mm.b (linha 15800). Ele é incluído em cada com¬ 
pilação e, ele, por sua vez, inclui todos os grandes arquivos 


de cabeçalho do sistema de /usr/include e seus subdire- 
tórios que são necessários para cada módulo objeto. A mai¬ 
oria dos arquivos incluídos em kernel/kernel. h também é 
incluída aqui. O gerenciador de memória igualmente pre¬ 
cisa de definições contidas em include/fcntl.h e include/ 
unistd.h. As versões próprias do gerenciador de memória 
para const.h, type.h,proto.h eglo.h, também são incluí¬ 
das. 

Const.h (linha 15900) define algumas constantes utili¬ 
zadas pelo gerenciador de memória, especialmente quan¬ 
do compilado para máquinas de 16 bits. A linha 

#define printf printk 

está aqui contida para que chamadas a printf sejam com¬ 
piladas como chamadas à função printk. A função é seme¬ 
lhante àquela que vimos no kernel e é definida por uma 
razão semelhante, para que o gerenciador de memória 
possa exibir mensagens de erro e de depuração sem cha¬ 
mar o sistema de arquivos para ajudar. 

Tvpe.h atualmente não é utilizada e existe na forma de 
esqueleto apenas para que os arquivos do gerenciador de 
memória tenham a mesma organização que as outras par¬ 
tes do MINIX. Proto.h (linha 16100) reúne em um lugar 
protótipos de função necessários em todo o gerenciador de 
memória. 

As variáveis globais do gerenciador de memória são 
declaradas em glo.h (linha 16200 ). O mesmo truque utili¬ 
zado no kernel com EXI’ERN é aqui utilizado. Ou seja, 
EXTERN é normalmente uma macro que se expande para 
extern, exceto no arquivo table. c. Aí, ela se toma uma string 
nula para que se possa reservar espaço para as variáveis 
declaradas como EXTERN. 

A primeira dessas variáveis, mp, é um ponteiro para 
uma estrutura mproc, a parte do gerenciador de memória 
na tabela de processos para o processo cuja chamada de 
sistema está sendo processada. A segunda variável 
dont_reply é iniciada como FALSE quando cada nova soli¬ 
citação chega, mas pode ser configurada como TRUE du¬ 
rante a chamada, se for descoberto que nenhuma mensa¬ 
gem de resposta deve ser enviada. Por exemplo, nenhuma 
resposta é enviada para uma EXEC bem-sucedida. A tercei¬ 
ra variável procs_in_use, monitora quantas entradas de 
processo estão atualmente em uso, tornando fácil ver se 
uma chamada FORK é praticável. 

Os buffers de mensagens mmjn e mm_out são para 
as mensagens de solicitação e de resposta respectivamente. 
Wbo é o índice do processo atual; é relacionado a mp por 

mp = &mproc [who]. 

Quando uma mensagem chega, o número da chamada de 
sistema é extraído dela e colocado em mm_call. 

As três variáveis err_code, result2 e res_ptr são utiliza¬ 
das para armazenar valores retornados para o processo 
chamador na mensagem de resposta. A mais importante 
dessas variáveis é err_code, configurada como OK se a cha¬ 
mada for completada sem erro. As últimas duas variáveis 
são utilizadas quando um problema ocorre. O minix grava 
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uma imagem de um processo em um arquivo de núcleo 
quando um processo termina anormalmente. Corejtame 
define o nome que o arquivo terá e core_sset é um mapa 
de bits que define quais sinais devem produzir dumps de 
núcleo. 

A parte do gerenciador de memória na tabela de pro¬ 
cessos está no próximo arquivo, mproc.h (linha 16300). A 
maioria dos campos é adequadamente descrita por seus 
comentários. Vários campos lidam com tratamento de si¬ 
nais. Mpjgnore. mp_catch , mp_sigmask , mp_sigmask2 
e mp_sigpending são mapas de bits, nos quais cada bit 
representa um dos sinais que pode ser enviado para um 
processo. O tiposigset_té um inteiro de 32 bits, portanto, o 
MlNix poderia com facilidade suportar até 32 sinais, mas 
atualmente apenas 16 sinais são definidos, com o sinal 1 
sendo o bit menos significativo (mais à direita). Em qual¬ 
quer caso, o POSix exige funções padrão para adicionar ou 
para excluir membros dos conjuntos de sinais representa¬ 
dos por esses mapas de bits para que toda manipulação 
necessária possa ser feita sem que o programador esteja 
ciente desses detalhes. A matriz mp_sigact é importante 
para tratar sinais. Há um elemento para cada tipo de sinal 
e cada elemento é uma estrutura sigaction (definida em 
mclude/signal.h). Cada estrutura sigaction consiste em três 
campos: 

1. O campo sa_handler define se o sinal deve ser tra¬ 
tado na maneira padrão, ignorado, ou tratado por 
um manipulador especial. 

2. O campo sa_mask é um sigsetj que define quais 
sinais devem ser bloqueados quando o sinal está 
sendo tratado por um manipulador personaliza¬ 
do. 

3. Ocamposw Jlagsé um conjunto de sinalizadores 
que se aplicam ao sinal. 

Essa matriz possibilita grande flexibilidade no tratamento 
de sinais. 

O campo mp Jlags é utilizado para armazenar uma 
variada coleção de bits como indicado no fim do arquivo. 
Esse campo é um inteiro sem sinal de 16 bits em CPUs de 
categoria inferior, ou de 32 bits em um 386 e superiores. 
Há abundância de espaço para expansão aqui mesmo em 
8088, uma vez que são utilizados apenas 9 bits. 

O último campo na tabela de processos é mp_procargs. 
Quando um novo processo é iniciado, uma pilha como a 
mostrada na Figura 4-39 é construída, e um ponteiro para 
o início da matriz argv do novo processo é armazenado 
aqui. Este é utilizado pelo comando/»,?. Assim, para o exem¬ 
plo da Figura 4-39, o valor 8164 seria armazenado aqui 
para permitir que/« exiba a linha de comando 

Is -I f.c g.c 

se executado enquanto o comando ls estiver ativo. 

O próximo arquivo é param.h (linha 16400) que con¬ 
tém macros para muitos dos parâmetros de chamada de 
sistemas contidos na mensagem de solicitação. Ele tam¬ 


bém contém quatro macros para campos na mensagem de 
resposta. Quando a declaração 

k = pid; 

aparece em qualquer arquivo em qu eparam.h é incluído, 
o pré-processador converte-o para 

k = mmjn.ml J1 ; 

antes de utilizá-lo para alimentar o próprio compilador. 

Antes de continuarmos com o código executável, va¬ 
mos examinar table.c (linha 16500). Sua compilação re¬ 
serva espaço de armazenamento para diversas variáveis e 
estruturas EXTERN vimos em glo.h e mproc.h. A decla¬ 
ração 

#define_TABLE 

faz com que EXTERN torne-se uma string nula. Esse é o 
mesmo mecanismo que vimos no código do kernel. 

O outro recurso importante de table.c é a matriz 
call_vec (linha 16515). Quando uma mensagem de soli¬ 
citação chega, o número da chamada de sistema é extraí¬ 
do dela e utilizado como um índice em calljuec para loca¬ 
lizar o procedimento que executa essa chamada de siste¬ 
ma. Todos os números de chamada de sistema que não 
correspondem a chamadas válidas invocam no_sys, que 
simplesmente retorna um código de erro. Note que, embo¬ 
ra a macro _PROTOTYPE seja utilizada ao definir call_vec. 
isso não é uma declaração de um protótipo; é a definição 
de uma matriz inicializada. Entretanto, é uma matriz de 
funções, e a utilização de _PROTOTYPE é a maneira mais 
fácil de tornar isso compatível tanto com o C clássico (Ker- 
nighan & Ritchie) como com o C padrão. 

4.8.2 Programa Principal 

O gerenciador de memória é compilado e linkeditado 
independentemente do kernel e do sistema de arquivos. 
Consequentemente, ele tem seu próprio programa princi¬ 
pal, iniciado depois que o kernel terminou sua própria ini¬ 
cialização. O programa principal está em main.c, na li¬ 
nha 16627. Depois de fazer sua própria inicialização cha¬ 
mando mmjnit, o gerenciador de memória entra no seu 
laço na linha 16636, onde ele chama getjvork para espe¬ 
rar uma mensagem de solicitação. Então, ele chama um 
dos procedimentos do_XXX via tabela calljuec para exe¬ 
cutar a solicitação e, por fim, enviar uma resposta, se ne¬ 
cessário. Essa construção deve ser familiar para você ago¬ 
ra: ela é a mesma utilizada pelas tarefas de E/S. 

Os procedimentos getjvork (linha 16663) e reply (li¬ 
nha 16676 ) tratam a recepção e 0 envio reais, respectiva¬ 
mente. 

O último procedimento nesse arquivo é mmjnit, que 
inicializa 0 gerenciador de memória. Ele não é utilizado 
depois que 0 sistema começa a executar. A chamada a 
sysjgetmap na linha 16730 obtém as informações sobre a 
utilização de memória do kernel. O laço nas linhas 16734 
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a l674l inicializa todas as entradas da tabela de processos 
para tarefas e para servidores, e as linhas seguintes prepa¬ 
ram a entrada da tabela de processos referente a init. Na 
linha 16749, 0 gerenciador de memória espera 0 sistema 
de arquivos enviar-lhe urna mensagem. Como menciona¬ 
do na discussão sobre tratamento de impasses no mínix, 
essa é a única vez que 0 sistema de arquivos envia uma 
mensagem de solicitação para 0 sistema de arquivos. A 
mensagem informa quanta memória está sendo utilizada 
pelo disco de RAM. A chamada a memjnit na linha 16755 
inicializa a lista de lacunas, chamando a tarefa de siste¬ 
ma. Depois disso, 0 gerenciamento de memória normal 
pode começar. Essa chamada também preenche as variá¬ 
veis total_clicks e free_clicks que completam as informa¬ 
ções que mmjnit precisa para imprimir uma mensagem 
que mostra a memória total, a utilização da memória pelo 
kernel, 0 tamanho do disco de RAM e a memória livre. 
Depois da mensagem ser impressa, uma resposta é enviada 
para 0 sistema de arquivos (linha 16764), permitindo que 
ele continue. Por fim, à tarefa de memória é dado 0 ende¬ 
reço da parte do gerenciador de memória na tabela de pro¬ 
cessos para o benefício do comando ps. 

4.8.3 Implementação de FORK, EXIT e 
WAIT 

As chamadas de sistema FORK, KXIT e WAIT são imple¬ 
mentadas pelos procedimentos doJork. do_mm_exít e 
do_wait no arquivo forkexit.c. 0 procedimento do Jork 
(linha 16832) segue os passos mostrados na Figura 4-37. 
Note que a segunda chamada a procs_in_use (linha 
16847) reserva as últimas entradas da tabela de processos 
ao superusuário. Ao calcular quanta memória 0 filho ne¬ 
cessita, a lacuna entre os segmentos de dados e de pilha é 
incluída, mas 0 segmento de texto não 0 é. Tanto se 0 texto 
do pai é compartilhado ou, se 0 processo tiver espaços I e D 
comuns, seu segmento de texto é de comprimento zero. 
Depois de fazer a computação é feita uma chamada a 
alloc_mem para obter a memória. Se isso for bem-sucedi¬ 
do, os endereços de base do filho e do pai são convertidos 
de cliques em bytes absolutos e sys_copy é chamado para 
enviar uma mensagem à tarefa de sistema para realizar a 
operação de cópia. 

Agora uma entrada está localizada na tabela de proces¬ 
sos. 0 teste anterior envolvendo procs_in_u.se garante que 
uma existirá. Depois que a entrada foi localizada, ela é pre¬ 
enchida, primeiro copiando a entrada do pai aí e, então, 
atualizando os campos mp_parent , mpjlags, mp_seg, 
mp_exitstatus e mp_sigstatus . Alguns desses campos exi¬ 
gem tratamento especial. 0 bit TRACED no campo mpjlags 
é zerado, uma vez que um filho não herda 0 status de de¬ 
puração. 0 campo mp_seg é uma matriz contendo ele¬ 
mentos para os segmentos de dados de texto e de pilha, e a 
parte de texto é mantida, apontando para 0 segmento de 
texto do pai se os sinalizadores indicam que esse é um pro¬ 
grama com I e D separados que pode compartilhar texto. 


0 próximo passo é atribuir um pid ao filho. A variável 
nextJid monitora 0 próximo pid a ser atribuído. Entre¬ 
tanto, é concebível que 0 seguinte problema poderia ocor¬ 
rer. Depois de atribuir, digamos, pid 20 a um processo de 
vida muito longa, 30.000 outros processos poderiam ser 
criados e destruídos e next_pid poderia voltar a 20 nova¬ 
mente. Atribuir um pid que ainda está em uso seria um 
desastre (supondo que alguém mais tarde tentasse sinali¬ 
zar 0 processo 20), então, pesquisamos a tabela inteira de 
processos para assegurar que 0 pid a ser atribuído já não 
está em uso. 

As chamadas a.çpx Jork e a tell Js informam 0 kernel e 
0 sistema de arquivos respectivamente de que um novo pro¬ 
cesso foi criado para que possam atualizar suas tabelas de 
processos. (Todos os procedimentos que começam comAjx_ 
são rotinas de biblioteca que enviam uma mensagem à ta¬ 
refa de sistema no kernel. solicitando um dos serviços da 
Figura 3-50). A criação e a destruição de processos sempre 
são iniciadas pelo gerenciador de memória e, então, pro¬ 
pagadas para 0 kernel e para 0 sistema de arquivos quan¬ 
do concluídas. 

A mensagem de resposta ao filho é enviada explicita¬ 
mente no fim de do Jork. A resposta para 0 pai, contendo 0 
pid do filho, é enviada pelo laço em main, como a resposta 
normal para uma solicitação. 

A próxima chamada de sistema tratada pelo gerencia¬ 
dor de memória é EXIT. O procedimento do_mm_exit (li¬ 
nha 16912) aceita a chamada, mas a maior parte do tra¬ 
balho é feita pela chamada para mm_exit algumas linhas 
mais para baixo. A razão para essa divisão de trabalho é 
que mm_exit também é chamada para cuidar de proces¬ 
sos encerrados por um sinal. O trabalho é 0 mesmo, mas os 
parâmetros são diferentes, então, é conveniente dividir as 
coisas dessa maneira. 

A primeira coisa que mm_exit faz é parar 0 temporiza¬ 
dor se 0 processo tiver um executando. Em seguida, 0 ker¬ 
nel e 0 sistema de arquivos são notificados de que 0 proces¬ 
so não é mais executável (linhas 16949 e 16950). A cha¬ 
mada para 0 procedimento de bibliotecaxpsmv// envia uma 
mensagem à tarefa de sistema, instruindo-a a marcar 0 
processo como não mais executável, assim ele não será mais 
agendado. Em seguida, a memória é liberada. Uma cha¬ 
mada a find_share determina se 0 segmento de texto está 
sendo compartilhado por outro processo e, se não, 0 seg¬ 
mento de texto é liberado por uma chamada a free_mem. 
Isso é seguido por outra chamada ao mesmo procedimen¬ 
to para liberar os dados e a pilha. Não vale a pena 0 proble¬ 
ma de decidir se toda a memória poderia ser liberada em 
uma chamada a free_mem . Se 0 pai estiver esperando, cle- 
anup é chamado para liberar a entrada na tabela de pro¬ 
cessos. Se 0 pai não estiver esperando, 0 processo torna-se 
um zumbi, indicado pelo bit HANGING na palavra 
mpjags. Tanto no caso de 0 processo ter sido completa¬ 
mente eliminado como no de ele haver sido transformado 
em um zumbi, a ação final de mm_exit é fazer um laço 
pela tabela de processos e pesquisar os filhos do processo 
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que acaba de terminar (linhas 16975 a 16982). Se qual¬ 
quer um for encontrado, ele é deserdado e torna-se filho de 
irtit. Se init estiver esperando, e um filho estiver pendura¬ 
do, cleanup, então, é chamada para esse filho. Essa lida 
com situações como a mostrada na Figura 4-43(a), onde 
vemos que o processo 12 está para sair e que seu pai, 7, está 
esperando-o. Cleanup será chamada para livrar-se de 12, 
então, 52 e 53 transformam-se em filhos de init , como mos¬ 
trado na Figura 4-43(b). Agora temos a situação de que 
53, que já saiu, é o filho de um processo fazendo um wait. 
Consequentemente, ele também pode ser limpo. 

Quando o processo pai faz um WAIT ou um WAITPID, o 
controle vai para o procedimento do_waitpid na linha 
16992. Os parâmetros fornecidos pelas duas chamadas são 
diferentes, e as ações esperadas também, mas a configura¬ 
ção feita nas linhas 17009 a 17011 prepara variáveis inter¬ 
nas para que do_waitpid possa executar as ações de qual¬ 
quer das duas chamadas. O laço nas linhas 17019 a 17041 
varre a tabela de processos inteira para ver se 0 processo 
tem algum filho e, se tiver, ele verifica se algum deles é um 
zumbi que agora pode ser limpo. Se um zumbi for encon¬ 
trado (linha 17026), ele será limpo e do_waitpid retorna¬ 
rá. O sinalizador dontjreply é ativado porque a resposta 
para 0 pai é enviada de dentro de cleanup, não do laço em 
main. Se um filho rastreado for encontrado, uma resposta 
será enviada para indicar que 0 processo está parado, e 
do_waitpid retorna. Dontjreply também é configurado 
como true para impedir que uma segunda resposta seja 
enviada por main. 

Se 0 processo que faz 0 wait não tiver nenhum filho, 
ele simplesmente obterá 0 retorno de um erro (linha 
17053), Se tiver filhos, mas nenhum for zumbi ou estiver 
sendo rastreado, será feito um teste para ver se do_waitpid 
foi chamada com um bit ligado para indicar que 0 pai não 
quer esperar. Se não (0 caso normal), um bit é ligado na 
linha 17047 para indicar que ele está esperando, e 0 pai é 
suspenso até que um filho termine. 

Quando um processo saiu e seu pai 0 está esperando, 
em qualquer ordem em que tais eventos ocorram, 0 proce¬ 
dimento cleanup (linha 17061) é chamado para executar 
os últimos rituais. Não há muito 0 que fazer a essa altura. 
0 pai é acordado a partir de sua chamada wait ou waitpid 


e recebe 0 pid do filho terminado, assim como os status de 
sinal e de saída dele. O sistema de arquivos já liberou a 
memória do filho, e 0 kernel já suspendeu 0 agendamen- 
to. Então, tudo 0 que 0 keimel agora precisa fazer é liberar 
a entrada da tabela de processos referente ao filho. 

4.8.4 Implementação de EXEC 

O código para EXEC segue 0 esboço da Figura 4-38. Ele 
está contido no procedimento do_e.xec (linha 17140). De¬ 
pois de fazer algumas simples verificações de validade, 0 
gerenciador de memória busca 0 nome do arquivo a ser 
executado a partir do espaço do usuário. Na linha 17172, 
envia uma mensagem especial para 0 sistema de arquivos, 
para alternar para 0 diretório do usuário, de modo que 0 
caminho recém-buscado seja interpretado em relação ao 
diretório de trabalho do usuário em vez de em relação ao 
diretório de trabalho do gerenciador de memória. 

Se 0 arquivo estiver presente e for executável, 0 geren¬ 
ciador de memória lê 0 cabeçalho para extrair os tama¬ 
nhos de segmento. Então, ele busca a pilha a partir do es¬ 
paço do usuário (linhas 17188 e 17189), verifica se 0 novo 
processo pode compartilhar texto com um processo que já 
está executando (linha 17196), aloca memória para a nova 
imagem (linha 17199), corrige os ponteiros fveja as dife¬ 
renças entre (b) e (c) na Figura 4-39] e lê os segmentos de 
texto (se necessário) e de dados (linhas 17221 a 17226). 
Por fim, ele processa os bits setuid e se/gid, atualiza a en¬ 
trada na tabela de processos e informa ao kernel que ele 
terminou, de modo que 0 processo possa ser agendado no¬ 
vamente 

Embora 0 controle de todos os passos esteja em do_exec, 
muitos dos detalhes são executados por procedimentos 
subsidiários dentro de exec.c. Read_header (linha 17272), 
por exemplo, não apenas lê 0 cabeçalho e retorna os tama¬ 
nhos de segmento, mas também verifica se 0 arquivo é um 
executável MINIX válido para 0 mesmo tipo de CPU para 0 
qual 0 sistema operacional está compilado. Isso é feito por 
compilação condicional do teste apropriado no momento 
em que 0 gerenciador de memória é compilado (linhas 
17322 a 17327). Read_header também verifica se todos 
segmentos ajustam-se no espaço de endereço virtual. 



Figura 4-43 (a) A situação quando 0 processo 12 está para sair. (b) A situação depois que ele saiu. 
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0 procedimento neu'_mem (linha 17366) verifica se 
há memória suficiente disponível para a nova imagem da 
memória. Ele procura por uma lacuna suficientemente 
grande para apenas os dados e a pilha, se o texto está sendo 
compartilhado; caso contrário, pesquisa uma única lacu¬ 
na suficientemente grande para texto, para dados e para 
pilha combinados. Uma possível melhoria aqui seria pes¬ 
quisar duas lacunas separadas, uma para o texto e outra 
para os dados e para a pilha, uma vez que não há nenhu¬ 
ma necessidade de essas áreas serem contíguas. Em ver¬ 
sões anteriores do minix isso era exigido. Se memória sufi¬ 
ciente for encontrada, a memória antiga é liberada e a nova 
memória adquirida. Se memória insuficiente estiver dis¬ 
ponível, a chamada exec falha. Depois que a nova é aloca¬ 
da, new_mem atualiza o mapa de memória (em mp_seg) 
e informa isso ao kernel chamando o procedimento de bi¬ 
blioteca sys_newmap. 

O restante de new_mem preocupa-se com zerar o seg¬ 
mento bss , a lacuna e o segmento de pilha. (0 segmento 
bss é aquela parte do segmento de dados que contém todas 
as variáveis globais não-inicializadas). Muitos compilado¬ 
res geram código explícito para zerar o segmento bss, mas 
fazer isso aqui permite que o MINIX funcione mesmo com 
compiladores que não o fazem. A lacuna entre os segmen¬ 
tos de dados e de pilha também é zerada, de modo que 
quando o segmento de dados é estendido por BRK, a memó¬ 
ria adquirida conterá zeros. Isso é uma conveniência para 
o programador, que pode contar com novas variáveis que 
têm um valor inicial de zero, como também um recurso de 
segurança em um sistema operacional multiusuário, onde 
um processo previamente utilizando essa memória pode 
ter utilizado dados que não deveriam ser vistos por outros 
processos. 

0 próximo procedimento épatcb_ptr (linha 17465), 
que faz o trabalho de realocar os ponteiros da Figura 4- 
39 (b) para a forma da Figura 4-39 (c). 0 trabalho é sim¬ 
ples: ele examina a pilha para localizar todos os ponteiros 
e adiciona o endereço de base a cada um. 

0 procedimento load_seg (linha 17498) é chamado 
uma ou duas vezes por EXEC, para possivelmente carregar 
o segmento de texto e sempre carregar o segmento de da¬ 
dos. Em vez de simplesmente ler o arquivo bloco por bloco 
e, então, copiar os blocos para o usuário, um truque é uti¬ 
lizado para permitir que o sistema de arquivos carregue o 
segmento inteiro diretamente para o espaço do usuário. 
Com efeito, a chamada é decodificada pelo sistema de ar¬ 
quivos de uma maneira ligeiramente especial para que 
pareça ser uma leitura do segmento inteiro pelo próprio 
processo do usuário. Somente algumas poucas linhas no 
começo da rotina de leitura do sistema de arquivos sabem 
que um truque está em andamento aqui. 0 carregamento 
é significativamente acelerado com essa manobra. 

0 procedimento final em exec.c é find_sbare (linha 
17535). Ele procura por um processo que pode comparti¬ 
lhar texto comparando o nó-i, o dispositivo e os tempos de 
modificação do arquivo a ser executado com aqueles dos 
processos existentes. Essa é uma pesquisa simples e direta 


dos campos apropriados em mproc. Naturalmente, ela deve 
ignorar o processo em nome do qual a pesquisa está sendo 
feita. 

4.8.5 Implementação de BRK 

Como acabamos de ver, o modelo de memória utiliza¬ 
do pelo MINIX é bem simples: a cada processo é dado uma 
única alocação contígua para seus dados e para sua pilha 
quando ele é criado. Ele nunca é movido na memória, 
nunca é comutado para fora da memória, nunca cresce e 
nunca encolhe. Tudo o que pode acontecer é que o seg¬ 
mento de dados pode consumir a lacuna a partir da extre¬ 
midade inferior, e a pilha consumir a partir da extremida¬ 
de superior. Sob essas circunstâncias, a implementação da 
chamada BRK em break.c é especialmente fácil. Consiste 
em verificar se os novos tamanhos são praticáveis e, então, 
atualizar as tabelas para refleti-los. 

0 procedimento de primeiro nível é do_brk (linha 
17628), mas a maior parte do trabalho é feita em adjust 
(linha 17661). Este último verifica se os segmentos de pi¬ 
lha e de dados colidiram. Se isso tiver acontecido, a cha¬ 
mada BRK não poderá ser executada, mas o processo não 
será eliminado imediatamente. Um fator de segurança, 
SAFETY_BYTES, é adicionado ao topo do segmento de da¬ 
dos antes de fazer o teste, então (espera-se) a decisão de 
que a pilha cresceu demais pode ser tomada enquanto ain¬ 
da há espaço suficiente na pilha para o processo continuar 
por um breve instante. Ele obtém o controle de volta (com 
uma mensagem de erro), e, então, pode imprimir mensa¬ 
gens apropriadas e desligar elegantemente. 

Note que SAFETY_BYTESé definido, utilizando uma de¬ 
claração #define no meio do procedimento (linha 17693). 
Essa utilização é bastante incomum: normalmente tais 
definições aparecem no começo de arquivos ou em arqui¬ 
vos de cabeçalho separados. 0 comentário associado reve¬ 
la que o programador achou que decidir sobre o tamanho 
do fator de segurança seria difícil. Não há dúvida de que 
essa definição foi feita assim para atrair atenção e, talvez, 
para estimular experimentação adicional. 

A base do segmento de dados é constante, então, se ad¬ 
just tiver de ajustar o segmento de dados, tudo o que ele 
tem a fazer é atualizar o campo de comprimento. A pilha 
cresce para baixo a partir de um ponto final fixo, assim, se 
adjust também notar que o ponteiro de pilha, que é dado 
para adjust como para um parâmetro, cresceu além do 
segmento de pilha (para um endereço mais baixo), tanto 
a origem como o comprimento são atualizados. 

0 último procedimento nesse arquivo, size_ok (linha 
17736) faz um teste para ver se os tamanhos de segmento 
ajustam-se dentro do espaço de endereço, em cliques as¬ 
sim como em bytes. 0 código condicional para máquinas 
de 16 bits foi mantido na listagem para mostrar por que 
isso é escrito como uma função separada. Haveria pouco 
problema em ter isso como uma função separada para 0 
MINIX de 32 bits. Ele é chamado somente em dois lugares, e 
colocar a linha 17765 no lugar das chamadas resultaria 
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em um código mais compacto, uma vez que as chamadas 
passam vários argumentos que não são utilizados na im¬ 
plementação de 32 bits. 

4.8.6 Implementação da Manipulação 
de Sinais 

Há oito chamadas de sistema que se relacionam com 
sinais, resumidas na Figura 4-44. Tais chamadas de siste¬ 
ma, assim como os próprios sinais, são processadas no ar¬ 
quivo signal.c. Uma chamada de sistema adicional, re- 
BOOT, também é tratada por esse arquivo, uma vez que uti¬ 
liza sinais para terminar todos os processos. 

A chamada SIGACTION suporta as funções sigaction e 
signal, que permitem que um processo altere a maneira 
como ele responderá aos sinais. Sigaction é exigida pelo 
POSix e é a chamada preferida para a maioria dos propósi¬ 
tos, mas a função de biblioteca signal é exigida pelo C pa¬ 
drão, e programas que devem ser portáveis para sistemas 
não-POSlX devem ser escritos, utilizando essa chamada. 0 
código para do_sigaction (linha 17845) começa verifican¬ 
do um número de sinal válido e verificando que a chama¬ 
da não é uma tentativa de alterar a resposta a um sinal 
SlGKii.i, (linhas 17851 e 17852). (Não é permitido ignorar, 
capturar ou bloquear SIGKILL. SIGKILL é o modo como, em 
última instância, o usuário pode controlar seus processos e 
um gerenciador de sistema pode controlar seus usuários.) 
sigaction é chamada com ponteiros para uma estrutura 
sigaction, sig_osa, que recebe os atributos de sinal antigos 
que estavam em efeito antes da chamada, e outra estrutu¬ 
ra desse tipo, sig_nsa, que contém um novo conjunto de 
atributos. 

0 primeiro passo é chamar a tarefa de sistema para 
copiar os atributos atuais na estrutura apontada por 
sig_osa. SIGACTION poder ser chamada com um ponteiro 
NULL em sigjnsa para examinar os atributos antigos de 
sinal sem alterá-los. Nesse caso, do_sigaction retoma ime¬ 
diatamente (linha 17860). S esig_nsa não íorNULL, a es¬ 
trutura que define a nova ação dos sinais é copiada para o 
espaço do gerenciador de memória. 0 código nas linhas 
17867 a 17877 modifica os mapas de bits mp_catch. 


mpjgnore e mp jsigpending de acordo com o fato de a 
nova ação ser ignorar o sinal, utilizar o manipulador pa¬ 
drão ou capturar o sinal. As funções de biblioteca sigadd- 
set e sigdelset são utilizadas apesar de as ações serem ope¬ 
rações simples e diretas de manipulação de bits que podi¬ 
am ter sido implementadas com macros simples. Entre¬ 
tanto, tais funções são exigidas pelo padrão POSIX para tor¬ 
nar os programas que as utilizam facilmente portáveis, 
mesmo para sistemas em que o número de sinais excede o 
número de bits disponíveis em um inteiro. A utilização das 
funções de biblioteca ajuda a tornar o próprio MINIX facil¬ 
mente portável para arquiteturas diferentes. 

Por fim, são preenchidos os outros campos relaciona¬ 
dos com sinais na parte do gerenciador de memória da ta¬ 
bela de processos. Para cada sinal possível, há um mapa de 
bits, sa_mask, que define quais sinais serão bloqueados 
enquanto um manipulador para esse sinal estiver execu¬ 
tando. Para cada sinal, também há um ponteiro sa_ 
handler. Esse pode conter um ponteiro para a função do 
manipulador ou valores especiais para indicar que o sinal 
deve ser ignorado ou ser tratado da maneira padrão. 0 en¬ 
dereço da rotina de biblioteca que invoca SIGRETURN quan¬ 
do o manipulador termina é armazenado em mp_sigre- 
turn. Esse endereço é um dos campos na mensagem rece¬ 
bidos pelo gerenciador de memória. 

O POSix permite que um processo manipule o próprio 
tratamento de sinal mesmo enquanto dentro de um mani¬ 
pulador de sinal. Isso pode ser utilizado para alterar a res¬ 
posta de sinal a sinais subseqüentes enquanto um sinal 
está sendo processado e, então, restaurar o conjunto de res¬ 
postas normais. O próximo grupo de chamadas de sistema 
suporta esses recursos de manipulação de sinal. SIGPEN- 
DING é tratada por do_sigpending (linha 17889), que re¬ 
torna o mapa de bits mp_sigpending para que um proces¬ 
so possa determinar se ele tem sinais pendentes. SIGPROC- 
mask, tratada por do_sigprocmask, retorna o conjunto de 
sinais que atualmente estão bloqueados e também pode 
ser utilizada para alterar o estado de um único sinal no 
conjunto ou para substituir o conjunto inteiro por um novo. 
O momento em que um sinal é desbloqueado é apropriado 
para verificar sinais pendentes e isso é feito por chamadas 


Chamada de sistema 

Propósito 

SIGACTION 

Modifica resposta para sinal futuro 

SIGPROCMASK 

Altera conjunto de sinais bloqueados 

KILL 

Envia sinal para outro processo 

ALARM 

Envia sinal de ALRM para si após intervalo 

PAUSE 

Suspende a si própria até sinal futuro 

SIGSUSPEND 

Altera conjunto de sinais bloqueados até então, PAUSE 

SIGPENDING 

Examina o conjunto de sinais pendentes (bloqueados) 

SIGRETURN 

Limpeza após manipulador de sinal 


Figura 4-44 Chamadas de sistema relacionadas com sinais. 
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a check_pending na linha 17927 e na linha 17933. 
Do_sigsuspend (linha 17949) executa a chamada de sis¬ 
tema SIGSUSPEND. Essa chamada suspende um processo até 
que um sinal seja recebido. Como as outras funções que 
discutimos aqui, essa manipula mapas de bits. Ela tam¬ 
bém liga o bit SIGSUSPEND em mp^flags, que é o neces¬ 
sário para impedir a execução do processo. Novamente, este 
é um bom momento para fazer uma chamada a check_ 
pending. Por fim, do_sigreturn trata SIGRETURN, que é uti¬ 
lizada para retornar de um manipulador personalizado. 
Ela restaura o contexto de sinal que existia quando o ma¬ 
nipulador foi iniciado e também chama check_pmding 
na linha 17980. 

Alguns sinais como SIGIXT, originam-se no próprio ker- 
nel. Esses sinais são tratados de uma maneira que é seme¬ 
lhante aos sinais gerados por um processo de usuário cha¬ 
mando KILL. Os dois procedimentos, dojtíll (linha 17983) 
e do_ksig (linha 17994), são conceitualmente semelhan¬ 
tes. Os dois fazem com que o gerenciador de memória en¬ 
vie um sinal. Uma única chamada a KIU. pode exigir en¬ 
trega de sinais para um grupo de processos, e do_kill sim¬ 
plesmente chama check_sig, que verifica destinatários ele¬ 
gíveis na tabela de processos inteira. Do_ksig é chamada 
quando chega uma mensagem do kernel. A mensagem 
contém um mapa de bits que permite que o kernel gere 
múltiplos sinais com uma mensagem. Como com KILL. cada 
uma dessas pode precisar ser entregue para um grupo de 
processos. O mapa de bits é processado um bit por vez pelo 
laço nas linhas 18026 a 18048. Alguns sinais do kernel re¬ 


querem atenção especial: o ID de processo é alterado em 
alguns casos para fazer com que o sinal seja entregue para 
um grupo de processos (linhas 18030 a 18033) e um si- 
GAI.R.M é ignorado se não for solicitado. Com essa exceção, 
cada conjunto de bits resulta em uma chamada a check_sig , 
assim como em do_kill. 

A chamada de sistema alarm é controlada por 
dojilarm (linha 18056). Ela chama a próxima função, 
set_alarm, que envia uma mensagem à tarefa de relógio, 
dizendo-lhe para iniciar o temporizador. Set_alarm (linha 
18067) é uma função separada, porque também é utiliza¬ 
da para desligar o temporizador quando um processo é en¬ 
cerrado com o temporizador ainda ligado. Quando o tem¬ 
porizador expira, o kernel anuncia o fato, enviando ao ge¬ 
renciador de memória uma mensagem do tipo KSIG, que 
faz com que do_ksig execute como discutido acima. A ação 
padrão do sinal S1GALRM é eliminar o processo se o sinal 
não for capturado. Se SIGALRM é para ser capturado, um 
manipulador deve ser instalado por SIGACTION. A seqüên- 
cia completa dos eventos para um sinal sigaerm com um 
manipulador personalizado é mostrada na Figura 4-45. Há 
três sequências de mensagens aqui. Nas mensagens (1), 
(2) e (3). o usuário faz uma chamada a aiarm via uma 
mensagem para o gerenciador de memória; o gerenciador 
envia uma solicitação para o relógio e este reconhece-a. 
Nas mensagens (4), (5) e (6), a tarefa de relógio envia o 
alarme para o gerenciador de memória, que chama a tare¬ 
fa de sistema para preparar a pilha do processo de usuário 
para execução do manipulador de sinal [como na Figura 


Camada 



Figura 4-45 As mensagens para um alarme. As mais importantes são: (1) Usuário faz alarm. (4) 
depois que o tempo configurado passou, o sinal chega. (7) O manipulador termina com uma chamada 
a SIGRETURN. Veja o texto para detalhes. 
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4-42 (b)], e a tarefa de sistema responde. A mensagem (7) 
é a chamada a SIGRETURX que ocorre quando o manipula¬ 
dor completa a execução. Em resposta, o gerenciador de 
memória envia uma mensagem (8) à tarefa de sistema para 
fazê-la completar a limpeza, e a tarefa de sistema responde 
com uma mensagem (9). A mensagem (6) em si não causa 
a execução do manipulador, mas a seqüência será mantida 
porque a tarefa de sistema, como uma tarefa, terá permis¬ 
são para completar seu trabalho devido ao algoritmo de 
agendamento de prioridade utilizado no Mixi.x. O manipu¬ 
lador é parte do processo do usuário e executará somente 
depois que a tarefa de sistema tiver concluído seu trabalho. 

Do_pause cuida da chamada de sistema pausk (linha 
18115). Tudo que é necessário é ligar um bit para impedir 
a resposta, mantendo assim o chamador bloqueado. O ker¬ 
nel nem mesmo precisa ser informado, uma vez que ele 
sabe que o chamador está bloqueado. 

A última chamada de sistema tratada em signal.c é 
reboot (linha 18128). Essa chamada é utilizada somente 
por programas especializados executáveis pelo superusuá- 
rio, mas serve para uma função importante. Ela assegura 
que todos os processos sejam encerrados de uma maneira 
ordenada e que o sistema de arquivos esteja sincronizado 
antes de a tarefa de sistema no kemel ser chamada para 
desligar. 0 encerramento de processos é feito utilizando 
check_sig para enviar um SIGKILL a todos os processos ex¬ 
ceto init. Essa é a razão por que REBOOT é incluída nesse 
arquivo. 

Várias funções de suporte em signal.c foram mencio¬ 
nadas de passagem. Agora as veremos em maiores deta¬ 
lhes. De longe, a mais importante ésig_proc (linha 18168), 
que realmente envia um sinal. Primeiro alguns testes são 
realizados. As tentativas de enviar para processos elimina¬ 
dos (linhas 18190 a 18192) ou pendurados (linhas 18194 
a 18196) são problemas sérios que causam uma pane de 
sistema. Um processo que atualmente está sendo depurado 
é interrompido quando sinalizado (linhas 18198 a 18202). 
Se 0 sinal deve ser ignorado, 0 trabalho de sig_proc está 
completo na linha 18204. Essa é a ação-padrão para al¬ 
guns sinais, por exemplo, os sinais que são exigidos pelo 
POSix, mas não são suportados pelo mixix. Se 0 sinal esti¬ 
ver bloqueado, a única ação que necessita ser executada é 
ligar um bit no mapa de bits mp_sigpending desse proces¬ 
so. 0 teste-chave (linha 18213) é distinguir processos que 
foram habilitados para capturar sinais daqueles que não 
foram. A essa altura, todas as outras considerações especi¬ 
ais foram eliminadas, e um processo que não pode captu¬ 
rar 0 sinal será encerrado. 

Os sinais que são elegíveis para serem capturados são 
processados nas linhas 18214 a 18249. Uma mensagem é 
construída para ser enviada ao kernel, algumas partes da 
qual são cópias das informações na parte do gerenciador 
de memória da tabela de processos. Se 0 processo a ser si¬ 
nalizado foi previamente suspenso por SIGSUSPEND, a más¬ 
cara de sinal que foi salva no momento da suspensão é 
incluída na mensagem; caso contrário, a máscara atual de 


sinal é incluída (linhas 18213 a 18217). Outros itens in¬ 
cluídos na mensagem são vários endereços no espaço do 
processo sinalizado: 0 manipulador do sinal, 0 endereço 
da rotina de biblioteca sigreturn a ser chamada na con¬ 
clusão do manipulador e 0 ponteiro atual de pilha. 

Em seguida, é alocado espaço na pilha do processo. A 
Figura 4-46 mostra a estrutura que é colocada na pilha. A 
parte sigcontext é colocada na pilha para conservá-la para 
uma restauração posterior, uma vez que a estrutura cor¬ 
respondente na tabela de processos é alterada ao preparar- 
se para a execução do manipulador de sinal. A parte si- 
gframe oferece um endereço de retorno para 0 manipula¬ 
dor de sinal e dados necessários para SIGRETURN completar 
a restauração do estado do processo quando 0 manipula¬ 
dor termina. O endereço de retorno e 0 ponteiro da moldu¬ 
ra não são realmente utilizados por nenhuma parte do Mi- 
NIX. Estão aí para enganar um depurador se qualquer pes¬ 
soa alguma vez tentar rastrear a execução de um manipu¬ 
lador de sinal. 

A estrutura a ser colocada na pilha do processo sinali¬ 
zado é claramente grande. O código nas linhas 18225 e 
18226 reserva espaço para ela, depois que uma chamada a 
adjust testa para ver se há espaço suficiente na pilha do 
processo. Se não houver espaço de pilha suficiente. 0 pro¬ 
cesso será eliminado, saltando para 0 rótulo doterminate 
usando 0 raramente utilizado goto de C (linhas 18228 e 
18229). 

Há um problema potencial com a chamada a adjust. 
Lembre-se de nossa discussão sobre a implementação de 
BRK, que adjust retorna um erro se a pilha estiver com 
SAFETY_BY1'ES. entrando no segmento de dados. A mar¬ 
gem extra de erro é proporcionada porque a validade da 
pilha somente pode ser verificada ocasionalmente por sof¬ 
tware. Essa margem de erro é provavelmente excessiva no 
caso atual, uma vez que se sabe exatamente quanto espaço 
é necessário na pilha para 0 sinal, e 0 espaço adicional é 
necessário somente para 0 manipulador de sinal, presumi¬ 
velmente uma função relativamente simples. É possível que 
alguns processos sejam terminados desnecessariamente 
porque a chamada a adjust falha. Isso é certamente me¬ 
lhor que ter programas que falham misteriosamente em 
outras ocasiões, mas 0 ajuste fino desses testes pode ser pos¬ 
sível. 

Se houver espaço suficiente na pilha, dois outros sina¬ 
lizadores são verificados. O sinalizador SA_NODEFER in¬ 
dica se 0 processo sinalizado está bloqueando mais sinais 
do mesmo tipo ao tratar um sinal. O sinalizador 
SA_RESETHAND informa se 0 manipulador de sinal deve 
ser reinicializado ao receber esse sinal. (Isso oferece emu¬ 
lação confiável da antiga chamada signal. Embora esse 
“recurso”’ freqüentemente seja considerado uma falha na 
chamada antiga, suporte a recursos antigos exige suportar 
suas falhas também). 0 kernel, então, é notificado, utili¬ 
zando a rotina de biblioteca sys_sendsig (linha 18242). 
Por fim, 0 bit que indica um sinal pendente é limpo, e 
unpause é chamada para terminar qualquer chamada de 
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Figura 4-46 As estrutura sigcont&xt e sigframe colocadas na pilha para preparar para um 
manipulador de sinal. Os registradores do processador são uma cópia da moldura de pilha 
utilizada durante uma comutação de contexto. 


sistema em que o processo possa estar pendurado. Quando 
o processo sinalizado executar em seguida, o manipulador 
de sinal executará. 

Agora examinemos o código de encerramento, marca¬ 
do pelo rótulo doterminate (linha 18250). 0 rótulo e um 
goto são a maneira mais fácil de tratar o possível fracasso 
da chamada adjust. Aqui, são processados os sinais que 
por uma razão ou outra não podem ou não devem ser cap¬ 
turados. A ação pode incluir um dump de núcleo, se isso 
for apropriado para o sinal e sempre acaba com o encerra¬ 
mento do processo como se ele tivesse saído, por meio de 
uma chamada a mm_exit (linha 18258). 

Check_sig (linha 18265) é onde o gerenciador de me¬ 
mória verifica se um sinal pode ser enviado. A chamada 

kill(0, sig) 

faz com que o sinal indicado seja enviado para todos os 
processos no grupo do chamador (i. e., todos os processos 
iniciados do mesmo terminal). Os sinais originários do 
kernel e do reboot tambe'm podem afetar múltiplos pro¬ 
cessos. Por essa razão check_sig, faz um laço nas linhas 


18288 a 18318, varrendo a tabela de processos para locali¬ 
zar todos os processos para os quais um sinal deve ser envi¬ 
ado. O laço contém um grande número de testes. Somente 
se todos eles tiverem sucesso, é que o sinal será enviado, 
chamando sigj/roc na linha 18315. 

Check Jtmding (linha 18330) é outra função chama¬ 
da várias vezes no código que acabamos de revisar. Ela faz 
um laço por todos os bits no mapa de bits mp_sigpending 
para o processo referenciado ■çox do_sigmask, do_sigretum 
ou do_sigsuspend, para ver se qualquer sinal bloqueado 
tornou-se desbloqueado. Ela chama sig_proc para enviar 
o primeiro sinal desbloqueado que ela localizar. Uma vez 
que todos os manipuladores de sinal acabam causando a 
execução de do_sigretum , isso basta para entregar por fim 
todos os sinais pendentes não-mascarados. 

O procedimento unpause (linha 18359) tem a ver com 
sinais que são enviados a processos suspensos nas chama¬ 
das a PAUSE, WAIT, READ, WRITE OU SIGSUSPEND. PAUSE, WA1T 
e sigsuspend podem ser verificadas consultando-se a parte 
do gerenciador de memória da tabela de processos, mas se 
nenhum desses for localizado, o sistema de arquivos deve 
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ser solicitado a utilizar sua própria função dojunpause 
para verificar uma possível queda em read ou em write. 
Em cada caso a ação é a mesma: uma resposta de erro é 
enviada para a chamada que espera, e o bit de sinalização 
que corresponde à causa da espera é zerado para que o pro¬ 
cesso possa reassumir sua execução e processar o sinal. 

O procedimento final nesse arquivo é dump_core (li¬ 
nha 18402), que grava dumps de núcleo no disco. Um 
dump de núcleo consiste em um cabeçalho com as infor¬ 
mações sobre o tamanho dos segmentos ocupados por um 
processo por uma cópia de todas as informações de status 
de um processo, obtidas copiando as informações referen¬ 
tes ao processo da tabela de processos do kernel e pela ima¬ 
gem da memória de cada um dos segmentos. Um depura- 
dor pode interpretar essas informações para ajudar o pro¬ 
gramador a determinar o que deu errado durante a execu¬ 
ção do processo. O código para gravar o arquivo é simples e 
direto. O problema potencial mencionado na seção anteri¬ 
or novamente surge aqui, mas de uma forma um pouco 
diferente. Para assegurar que o segmento de pilha a ser re¬ 
gistrado no dump de núcleo está atualizado, adjust é cha¬ 
mada na linha 18428. Essa chamada pode falhar por causa 
da margem de segurança embutida. O sucesso da chamada 
não é verificado por dump_core, então, o dump de núcleo 
será gravado em qualquer caso, mas dentro do arquivo as 
informações sobre a pilha podem estar incorretas. 

4.8.7 Implementação das Outras 
Chamadas de Sistema 

0 arquivo getset.c contém um procedimento, do_getset 
(linha 18515), que executa as sete chamadas do gerencia¬ 
dor de memória restantes. Elas são mostradas na Figura 4- 
47. Todas são tão simples que não merecem um procedi¬ 
mento inteiro para cada uma. As chamadas GETUID e GET- 
GID retornam o uid e o gid real ou efetivo. 

A configuração de uid ou de gid é ligeiramente mais 
complexa do que a simples leitura. Uma verificação preci¬ 
sa ser feita para ver se o chamador é autorizado a configu¬ 
rar uid ou gid. Se o chamador passar no teste, o sistema de 
arquivos deve ser informado do novo uid ou gid, uma vez 
que a proteção de arquivos depende dele. A chamada SET- 


SID cria uma nova sessão, e um processo que já é líder de 
grupo de processos não tem permissão para fazer isso. 0 
teste na linha 18561 verifica isso. 0 sistema de arquivos 
completa o trabalho de tornar líder de sessão um processo 
sem controle do terminal. 

Um suporte mínimo para depuração, por meio da cha¬ 
mada de sistema PTRACE, está no arquivo trace.c. Há 11 
comandos que podem ser dados como um parâmetro para 
a chamada de sistema ptrace. Eles são mostrados na Fi¬ 
gura 4-48. No gerenciador de memória, dojrace processa 
quatro deles: enable, exit, resume e step. As solicitações 
para ativar ou para sair do rastreamento são completadas 
aqui. Todos os outros comandos são passados para a tarefa 
de sistema, que tem acesso à parte do kernel da tabela de 
processos. Isso é feito pela chamada à função de biblioteca 
sysjrace na linha 18669- Duas funções de suporte para 
rastreamento são oferecidas no fim de trace. c. Stop Jroc é 
utilizado para interromper um processo rastreado quando 
ele é sinalizado, e findproc oferece suporte a dojrace. lo¬ 
calizando na tabela de processos o processo a ser rastreado. 


4.8.8 Utilitários do Gerenciador de 
Memória 


Os arquivos restantes contêm tabelas e rotinas utilitári¬ 
as. O arquivo alloc.cé onde o sistema monitora quais par¬ 
tes da memória estão em uso e quais estão livres. Ele tem 
quatro pontos de entrada: 


1. alloc_mem 

2. freejnem 

3. maxjole 

4. memjnit 


solicita um bloco de memória de 
um dado tamanho, 
retoma memória que não é mais 
necessária. 

calcula o tamanho da maior la¬ 
cuna disponível. 

inicializa a lista de livres quando 
o gerenciador de memória inicia 
sua execução. 


Como dissemos antes, alloc_mem (linha 18840) sim¬ 
plesmente utiliza primeiro ajuste em uma lista de lacunas 
classificadas por endereço de memória. Se encontrar um 
pedaço que é muito grande, ela toma o que precisa e deixa 


Chamada de sistema 

Descrição 

GETUID 

Retorna o uid real e efetivo 

GETGID 

Retorna o gid real e efetivo 

GETPID 

Retorna os pids do processo e seu pai 

SETUID 

Configura o uid real e efetivo do chamador 

SETGID 

Configura o gid real e efetivo do chamador 

SETSID 

Cria nova sessão, retorna o pid 

GETPRP 

Retorna o ID do grupo do processo 


Figura 4-47 As chamadas de sistema suportadas em mm/getset. c. 
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Comando 

Descrição 

T_STOP 

Pára 0 processo 

T_OK 

Habilita 0 rastreamento desse processo pelo pai 

T_GETINS 

Retorna valor do espaço de texto (instruções) 

T_GETDATA 

Retorna valor do espaço de dados 

T_GETUSER 

Retorna valor da tabela de processos do usuário 

T_SETINS 

Configura um valor no espaço de instruções 

T_SETDATA 

Configura um valor no espaço de dados 

T_SETUSER 

Configura um valor na tabela de processos do usuário 

T_RESUME 

Reassume a execução 

T_EXIT 

Sai 

T_STEP 

Configura 0 bit de rastreio 


Figura 4-48 Comandos de depuração suportados por mm/trace. c. 


o restante na lista de livres, mas reduzido em tamanho pela 
quantidade tomada. Se uma lacuna inteira é necessária, 
del_slot (linha 18926) é chamada para remover a entrada 
da lista de livres. 

0 trabalho de free_mem é verificar se um pedaço re¬ 
centemente liberado de memória pode ser fundido com la¬ 
cunas de qualquer um dos lados. Se puder, meige (linha 
18949) é chamado para unir as lacunas e atualizar as lis¬ 
tas. 

Max_hole (linha 18985) varre a lista de lacunas e re¬ 
toma o maior item que encontrar. Memjnit (linha 19005) 
constrói a lista de livres inicial, consistindo em toda a me¬ 
mória disponível. 

0 próximo arquivo é o utility.c , que armazena alguns 
procedimentos diversos utilizados em vários lugares no 
gerenciador de memória. O procedimento alloued (linha 
I 912 O) verifica se um dado acesso é permitido para um 
arquivo. Por exemplo, do_exec precisa saber se um arqui¬ 
vo é executável. 

0 procedimento no_sys (linha 19 l 6 l) nunca dever ser 
chamado. Ele é oferecido somente no caso de um usuário 
em algum momento chama 0 gerenciador de memória com 
um número de chamada de sistema que é inválido ou que 
não é tratado pelo gerenciador de memória. 

Panic (linha 19172) é chamado somente quando 0 
gerenciador de memória detectou um erro do qual não pode 
recuperar-se. Ele informa 0 erro à tarefa de sistema, que, 
então, causa uma suspensão brusca do MINIX. Panic não é 
chamado incolumemente. 

A última função em utility.c é tell_fs , que constrói uma 
mensagem e envia-a para 0 sistema de arquivos, quando 
este último precisa ser informado dos eventos tratados pelo 
gerenciador de memória. 

Os dois procedimentos no arquivo putk.c também são 
utilitários, embora de um caráter bem diferente dos anteri¬ 
ores. De vez em quando, chamadas a printf são inseridas 
no gerenciador de memória, principalmente para depura¬ 


ção. Além disso, panic chama printf. Como já menciona¬ 
do, 0 nome printf é realmente uma macro definida como 
printk , de modo que chamadas a printf não utilizam 0 pro¬ 
cedimento-padrão de biblioteca de E/S que envia mensa¬ 
gens para 0 sistema de arquivos. Printk chama putk para 
comunicar-se diretamente com a tarefa de terminal, algo 
que é proibido para usuários comuns. Vimos uma rotina 
de mesmo nome no código do kernel. 

4.9 RESUMO 

Neste capítulo, examinamos 0 gerenciamento de me¬ 
mória, tanto em geral como no minix. Vimos que os siste¬ 
mas mais simples não fazem troca em disco (swap) ou 
paginação. Uma vez que um programa é carregado na me¬ 
mória, ele fica aí até terminar. Alguns sistemas operacio¬ 
nais permitem somente um processo por vez na memória, 
enquanto outros suportam multiprogramação. 

O próximo passo é a troca em disco. Quando a troca em 
disco é utilizada, 0 sistema pode tratar mais processos além 
do espaço disponível na memória. Os processos para os 
quais não há espaço são trocados para 0 disco. Espaço livre 
na memória e em disco pode ser monitorado com um mapa 
de bits ou de uma lista de lacunas. 

Computadores mais avançados, freqüentemente, têm 
alguma variante de memória virtual. Na forma mais sim¬ 
ples, 0 espaço de endereços de cada processo é dividido em 
blocos de tamanho uniforme chamados páginas, que po¬ 
dem ser colocadas em qualquer moldura de página dispo¬ 
nível na memória. Há muitos algoritmos de substituição 
de páginas, dois dos melhores conhecidos são 0 de segun¬ 
da chance e 0 de idade. Para fazer os sistemas de pagina¬ 
ção funcionar bem, não é suficiente escolher um algorit¬ 
mo: é necessária atenção a questões como determinar 0 
conjunto funcional, a política de alocação de memória e 0 
tamanho de página. 
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A segmentação ajuda no tratamento de estruturas de 
dados que mudam de tamanho durante a execução e sim¬ 
plifica a vinculação e o compartilhamento. Também faci¬ 
lita oferecer proteção diferente para segmentos diferentes. 
Às vezes, segmentação e paginação são combinadas para 
oferecer uma memória virtual de duas dimensões. O siste¬ 
ma MUi.Tics e o Pentium da Intel suportam segmentação e 
paginação. 

0 gerenciamento de memória no MINLX é simples. A 
memória é alocada quando um processo executa uma cha¬ 
mada de sistema fork ou Exile. A memória assim alocada 
nunca é aumentada ou diminuída durante a vida do pro¬ 
cesso. Nos processadores Intel, há dois modelos de memó¬ 
ria utilizados pelo MINLX. Os programas pequenos podem 
ter instruções e dados no mesmo segmento da memória. 
Programas maiores utilizam espaços de instruções e de 
dados separados (I e D separados). Os processos com espa¬ 
ços I e D separados podem compartilhar a parte de texto de 


E X E R C 

1. Um sistema de computador tem espaço suficiente para ar¬ 
mazenar quatro programas em sua memória principal. Es¬ 
ses programas ficam inativos esperando E/S metade do tem¬ 
po. Que fração de tempo da CPU é desperdiçada? 

2. Considere um sistema de troca em disco no qual a memória 
consiste nos seguintes tamanhos de lacuna pela ordem de 
memória: 10K.4K, 20K, 18K, 7K, 9K, 12Ke 15K. Que lacuna 
é tomada para sucessivas solicitações de segmento de 

(a) 12K 

(b) 10K 

(c) 9K 

no caso do algoritmo de primeiro aj uste? Agora repita a per¬ 
gunta para melhor ajuste, pior ajuste e próximo ajuste. 

3. Qual é a diferença entre um endereço físico e um endereço 
virtual? 

4. Utilizando a tabela de páginas da Figura 4-8, forneça o en¬ 
dereço físico correspondente a cada um dos seguintes ende¬ 
reços virtuais: 

(a) 20 

(b) 4100 

(c) 8300 

5. O processador Intel 8086 não suporta memória virtual. Con¬ 
tudo, algumas empresas chegaram a comercializar sistemas 
que continham uma CPU 8086 não-modificada e que fazi¬ 
am paginação. Faça uma suposição elaborada de como eles 
faziam isso. (Sugestão: pense na posição lógica da MMU.) 

6. Se uma instrução leva 1 microssegundo, e uma falha de pá¬ 
gina leva mais n microssegundos, forneça uma fórmula para 
o tempo efetivo de instrução se falhas de página ocorrerem 
a cada k instruções. 

7. Uma máquina tem um espaço de endereço de 32 bits e pági¬ 
nas de 8K. A tabela de páginas está inteiramente em har- 


sua memória, portanto, durante um FORK deve ser alocada 
memória apenas para dados e para pilha. Isso também pode 
ser verdadeiro durante um EXEC se outro processo já estiver 
utilizando o texto necessário pelo novo programa. 

A maior parte do trabalho do gerenciador de memória 
não é dedicada a monitorar a memória livre, o que ele faz 
utilizando uma lista de lacunas e o algoritmo do primeiro 
ajuste, mas sim, a executar as chamadas de sistema relaci¬ 
onadas com o gerenciamento de memória. Diversas cha¬ 
madas de sistema suportam sinais no estilo posix e, uma 
vez que a ação-padrão da maioria dos sinais é encerrar o 
processo sinalizado, é apropriado tratá-los no gerenciador 
de memória, que inicia o encerramento de todos os proces¬ 
sos. Várias chamadas de sistema não diretamente relacio¬ 
nadas com memória também são tratadas pelo gerencia¬ 
dor de memória, principalmente porque ele é menor que o 
sistema de arquivos e assim foi mais conveniente colocá-la 
aqui. 


í C I O s 

dware, com uma palavra de 32 bits por entrada. Quando um 
processo inicia, a tabela de páginas é copiada para o har¬ 
dware a partir da memória a uma taxa de uma palavra a 
cada lOOns. Se cada processo executa por lOOms (incluindo 
o tempo de carregar a tabela de página), que fração de tem¬ 
po da CPU é dedicada para carregar as tabelas de páginas? 

8. Um computador com endereços de 32 bits utiliza uma tabe¬ 
la de página de dois níveis. Endereços virtuais são divididos 
em um campo de 9 bits da tabela de páginas de primeiro 
nível, um campo de 11 bits da tabela de páginas de segundo 
nível e um deslocamento. Qual é o tamanho das páginas e 
quantas existem no espaço de endereços? 

9. A seguir é apresentada a listagem de um programa curto de 
linguagem assembly para um computador com páginas de 
512 bytes. O programa está localizado no endereço 1020, e 
seu ponteiro de pilha está em 8192 (a pilha cresce em dire¬ 
ção a 0). Forneça a cadeia de referências de páginas gerada 
por esse programa. Cada instrução ocupa 4 bytes (1 pala¬ 
vra) e referências tanto de instruções como de dados con¬ 
tam na cadeia de referências. 

Carregue a palavra 6144 no registrador 0 
Coloque o registrador 0 na pilha 
Chame um procedimento em 5120, colocando o endere¬ 
ço de retorno na pilha 

Subtraia a constante imediata 16 do ponteiro da pilha 
Compare o parâmetro real com a constante imediata 4 
Salte se igual a 5152 

10. Suponha que um endereço virtual de 32 bits seja quebrado 
em quatro campos, a,b,ce d. Os primeiros três são utiliza¬ 
dos para um sistema de tabela de páginas de três níveis. O 
quarto campo, d, é o deslocamento. O número de páginas 
depende dos tamanhos de todos os quatro campos? Se não, 
quais importam e quais não? 
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11. Um computador cujos processos têm 1.024 páginas em seu 
espaço de endereços mantém suas tabelas de páginas na 
memória. 0 overhead exigido para ler uma palavra da ta¬ 
bela de páginas é 500ns. Para reduzir esse overhead, o com¬ 
putador tem um UB, que armazena 32 pares (página virtu¬ 
al, moldura de página física) e pode fazer uma busca em 
lOOns. Qual a taxa de acertos necessária para reduzir o 
overhead médio para 200ns? 

12. 0 TI.B no VAX não contém um bit A 1 . Por quê? 

13. Uma máquina tem endereços virtuais de 48 bits e endereços 
físicos de 32 bits. As páginas são de 8K. Quantas entradas 
são necessárias na tabela de páginas? 

14. Um computador tem quatro molduras de página. 0 tempo 
de carregamento o tempo do último acesso e os bits R e M 
para cada página são como mostrado a seguir (os tempos 
estão em tiques do relógio): 


Página Carregado Última ref. 

R 

M 

0 

126 279 

0 

0 

1 

230 260 

1 

0 

2 

120 272 

1 

1 

3 

160 280 

1 

1 

(a) 

Que página NRU substituirá? 



(b) 

Que página FIFO substituirá? 



(c) 

Que página LRU substituirá? 



(d) 

Que página o algoritmo de segunda chance substituirá? 


15. Se a substituição de página F1F0 for utilizada com quatro 
molduras de página e oito páginas, quantas falhas de pági¬ 
na ocorrerão com a cadeia de referências 0172327103 se as 
quatro molduras estão inicialmente vazias? Agora repita esse 
problema para LRü. 

16. Um computador pequeno tem quatro molduras de página. 
No primeiro tique de relógio, os bits /? são 0111 (a página 0 
é 0, as restantes são 1). Em subseqüentes tiques de relógio, 
os valores são 1011,1010,1101,0010,1010, 1100e0001.Se 
o algoritmo de idade for utilizado com um contador de 8 
bits, forneça os valores dos quatro contadores depois do últi¬ 
mo tique. 

17. Quanto tempo leva para carregar um programa de 64K de 
um disco cujo tempo médio de busca é 30ms. seu tempo de 
rotação é 20ms e cujas trilhas armazenam 32K? 

(a) para um tamanho de página 2K? 

(b) para um tamanho de página 4K? 

As páginas são distribuídas aleatoriamente no disco. 

18. Uma das primeiras máquinas de compartilhamento de tem¬ 
po, o PDP-1, tinha uma memória de 4K palavras de 18 bits. 
Ele mantinha um processo por vez na memória. Quando o 
agendador decidia executar outro processo, o processo na 
memória era gravado em um tambor de paginação, com 4K 
palavras de 18 bits em torno da circunferência do tambor. O 
tambor poderia iniciar gravação (ou leitura) em qualquer 
palavra, em vez de somente na palavra 0. Por que você su¬ 
põe que esse tambor foi escolhido? 

19. Um computador oferece a cada processo 65.536 bytes de es¬ 
paço de endereço dividido em páginas de 4096 bytes. Um 
programa particular tem um tamanho de texto de 32.768 
bytes, um tamanho de dados de 16.386 bytes e um tamanho 
de pilha de 15.870 bytes. Esse programa ajustar-se-á no es¬ 
paço de endereço? Se o tamanho de página fosse 512 bytes. 


ele se ajustaria? Lembre-se de que uma página não pode 
conter partes de dois segmentos diferentes. 

20. Foi observado que o número de instruções executadas entre 
falhas de página é diretamente proporcional ao número de 
molduras de página alocadas para um programa. Se a me¬ 
mória disponível é dobrada, o intervalo médio entre falhas 
de página também dobra. Suponha que uma instrução nor¬ 
mal leve 1 microssegundo. mas se uma falha de página ocor¬ 
re, ela leva 2.001 microssegundos (i. e.. 2ms para tratar a 
falha). Se um programa levasse 60 s para executar, tempo 
durante o qual ocorressem 15.000 falhas de página, quanto 
levaria para executar se o dobro da memória estivesse dis¬ 
ponível? 

21. Um grupo de projetistas de sistema operacional da Compa¬ 
nhia Frugal de Computadores está pensando sobre manei¬ 
ras de reduzir a quantidade de espaço necessário para seu 
novo sistema operacional. O guru-chefe sugeriu apenas não 
se incomodar em salvar o texto de programa ao fazer uma 
troca em disco, mas simplesmente paginá-lo diretamente a 
partir do arquivo binário sempre que for necessário. Há al¬ 
gum problema com essa abordagem? 

22. Explique a diferença entre fragmentação interna e fragmen¬ 
tação externa. Qual ocorre em sistemas de paginação? Qual 
ocorre em sistemas que utilizam segmentação pura? 

23. Quando tanto segmentação como paginação são utilizadas, 
como no MULTICS, primeiro o descritor de segmento deve ser 
pesquisado, depois o descritor de página. O TLB também 
funciona dessa maneira, com dois níveis de pesquisa? 

24. Por que o esquema de gerenciamento de memória do MINIX 
torna necessário ter um programa como chmeti ? 

25. Modifique o MINIX para liberar a memória de um zumbi as¬ 
sim que ele entra no estado zumbi, em vez de aguardar até 
que o pai comece a esperá-lo. 

26. Na implementação atual do MINIX. quando uma chamada 
de sistema exec é feita, o gerenciador de memória verifica 
se uma lacuna suficientemente grande para conter a nova 
imagem da memória está atualmente disponível. Se não es¬ 
tiver, a chamada é rejeitada. Um algoritmo melhor seria ver 
se uma lacuna suficientemente grande estaria disponível de¬ 
pois que a imagem atual de memória fosse liberada. Imple¬ 
mente esse algoritmo. 

27. Quando executa uma chamada de sistema EXEC, o MINIX 
utiliza um truque para fazer o sistema de arquivos ler seg¬ 
mentos inteiros de uma vez. Invente e implemente um tru¬ 
que semelhante para permitir que dumps de núcleo sejam 
gravados de uma maneira semelhante. 

28. Modifique o minix para fazer troca em disco. 

29. Na Seção 4.7.5, foi indicado que, em uma chamada exec, 
testando-se para uma lacuna adequada antes de liberar a 
memória do processo atual, uma implementação subótima 
é alcançada. Reprograme esse algoritmo para fazer melhor. 

30. Na Seção 4.8.4, foi indicado que seria melhor pesquisar la¬ 
cunas para os segmentos de texto e de dados separadamen¬ 
te. Implemente esse aprimoramento. 

31. Redesenhe adjust para evitar o problema de os processos 
sinalizados serem eliminados desnecessariamente por cau¬ 
sa de um teste muito estrito para espaço de pilha. 
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Sistemas de Arquivos 


Todo aplicativo de computador precisa armazenar e 
recuperar informações. Enquanto um processo está execu¬ 
tando, ele pode armazenar uma quantidade limitada de 
informações dentro de seu próprio espaço de endereços. 
Entretanto, a capacidade de armazenamento é limitada ao 
tamanho do espaço de endereço virtual. Para alguns apli¬ 
cativos, esse tamanho é adequado, mas para outros, como 
reservas de linha aérea, sistemas bancários ou registro ge¬ 
ral de grandes corporações, é, de longe, muito pequeno. 

Um segundo problema com manter as informações 
dentro do espaço de endereços de um processo, é que quando 
o processo termina, as informações são perdidas. Para 
muitos aplicativos (p. ex., para bancos de dados), as infor¬ 
mações devem ser mantidas durante semanas, meses ou 
mesmo etemamente. É inaceitável que elas desapareçam 
quando o processo que as utiliza termina. Além disso, elas 
não devem desaparecer quando uma falha do computador 
“mata” o processo. 

Um terceiro problema: freqüentemente é necessário que 
múltiplos processos acessem as informações ou parte das 
informações ao mesmo tempo. Se temos uma lista de tele¬ 
fones on-line armazenada no espaço de endereços de um 
único processo, somente aquele processo pode acessá-la. A 
maneira de resolver esse problema é tornar as próprias in¬ 
formações independentes de qualquer processo. 

Assim, temos três exigências essenciais para armaze¬ 
namento de informações de longo prazo: 

1. Deve ser possível armazenar uma grande quanti¬ 
dade de informações. 

2. A informação deve sobreviver à finalização do pro¬ 
cesso que a utiliza. 

3. Múltiplos processos devem ser capazes de acessar 
as informações concorrentemente. 

A solução normal para todos esses problemas é armazenar 
as informações em discos e em outras mídias externas, em 


unidades chamadas arquivos. Os processos, então, podem 
lê-los e gravar novas informações se necessário. As infor¬ 
mações armazenadas em arquivos devem ser persisten¬ 
tes, isto é, não devem ser afetadas pela criação e pela fina¬ 
lização de processos. Um arquivo deve desaparecer apenas 
quando seu proprietário explicitamente removê-lo. 

Os arquivos são gerenciados pelo sistema operacional. 
0 modo como eles são estruturados, nomeados, acessados, 
utilizados, protegidos e implementados constitui temas 
importantes no projeto de um sistema operacional. Como 
um todo, a parte do sistema operacional que lida com ar¬ 
quivos é conhecida como o sistema de arquivos, sendo o 
assunto deste capítulo. 

Do ponto de vista do usuário, o aspecto mais importan¬ 
te de um sistema de arquivos é como aparece para ele, isto 
é, o que constitui um arquivo, como os arquivos são no¬ 
meados e protegidos, que operações são permitidas em ar¬ 
quivos e assim por diante. Os detalhes de como listas enca¬ 
deadas ou mapas de bits são utilizados para registrar o es¬ 
paço livre e quantos setores estão em um bloco lógico são 
de interesse menor, embora sejam de grande importância 
para os projetistas do sistema de arquivos. Por essa razão, 
estruturamos o capítulo em várias seções. As duas primei¬ 
ras são dedicadas à interface do usuário para arquivos e 
para diretórios, respectivamente. Então, vem uma detalhada 
discussão sobre como é implementado o sistema de arqui¬ 
vos. Depois, veremos mecanismos de proteção e de segu¬ 
rança em sistemas de arquivos. Por fim, será enfocado o 
sistema de arquivos. 


5.1 ARQUIVOS 

Nesta seção, veremos arquivos do ponto de vista do usu¬ 
ário, isto é, como eles são utilizados e quais são suas pro¬ 
priedades. 
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5.1.1 Nomes de Arquivo 

Os arquivos são um mecanismo de abstração. Ofere¬ 
cem uma maneira de armazenar as informações no disco 
e de lê-las de volta mais tarde. Isso deve ser feito de tal 
maneira que esconda do usuário os detalhes de como e 
onde as informações são armazenadas e de como os discos 
realmente trabalham. 

Provavelmente, a mais importante característica de 
qualquer mecanismo de abstração é a maneira como são 
nomeados os objetos que estão sendo gerenciados. Assim, 
iniciaremos nosso exame dos sistemas de arquivos com o 
tema atribuição de nomes de arquivo. Quando um proces¬ 
so cria um arquivo, ele lhe dá um nome. Quando o proces¬ 
so termina, o arquivo continua a existir e a poder ser aces¬ 
sado por outros processos, utilizando seu nome. 

As regras exatas para nomes de arquivos variam um 
pouco de um sistema para outro, mas todos os sistemas 
operacionais permitem cadeias de uma a oito letras como 
nomes de arquivo válidos. Assim andrea, bruce e cathy 
são nomes possíveis de arquivo. Freqüentemente, algaris¬ 
mos e caracteres especiais também são permitidos, então, 
nomes como 2, urgente! e Fíguva. 2-14 freqüentemente 
são válidos também. Muitos sistemas de arquivos supor¬ 
tam nomes com até 255 caracteres. 

Alguns sistemas de arquivos distinguem entre nomes 
escritos com letras maiusculas e nomes escritos com letras 
minúsculas, enquanto outros não o fazem. O UNIX entra 
na primeira categoria; o MS-DOS entra na segunda. Assim 
um sistema UNIX pode ter todos os seguintes nomes como 
arquivos distintos: barbara , Barbara , BARBARA, BARba- 
ra e BarBaRa. No MS-DOS, todos eles designam o mesmo 
arquivo. 

Muitos sistemas operacionais suportam nomes de ar¬ 
quivo de duas partes, ambas separadas por um ponto, como 


em prog. c. A parte que se segue ao ponto é chamada exten¬ 
são de arquivo e normalmente indica algo sobre o arquivo. 
No MS-DOS, por exemplo, nomes de arquivo têm de 1 a 8 
caracteres, com mais uma extensão opcional de 1 a 3 ca¬ 
racteres. No UNIX, o tamanho da extensão, se houver uma, 
é o usuário quem determina, e um arquivo pode ter até 
duas ou mais extensões, como em prog.c.Z, onde Z é co- 
mumente utilizado para indicar que o arquivo (oprog. c) 
foi compactado, utilizando o algoritmo de compactação 
de Ziv-Lempel. Algumas extensões de arquivo mais comuns 
e seus significados são mostrados na Figura 5-1. 

Em alguns casos, as extensões de arquivo são apenas 
convenções e não são necessáriamente impostas. Um ar¬ 
quivo chamado arquivo.txt é provavelmente algum tipo 
de arquivo de texto, mas esse nome é mais para lembrar o 
proprietário do que para carregar quaisquer informações 
específicas para o computador. Por outro lado, um compi¬ 
lador C, ao compilar, pode realmente insistir em que os 
arquivos sejam terminados em.ce pode recusar-se a com¬ 
pilá-los se essa exigência não for atendida. 

Convenções como essa são especialmente úteis quando 
o mesmo programa pode tratar vários tipos diferentes de 
arquivos. 0 compilador C, por exemplo, pode receber uma 
lista de vários arquivos a compilar e a vincular juntos, sen¬ 
do alguns deles arquivos em C e, outros, arquivos em lin¬ 
guagem assembly. A extensão, então, torna-se essencial 
para informar ao compilador quais são arquivos em C, quais 
são em assembly e quais são outros arquivos. 

5.1.2 Estruturas de Arquivos 

Os arquivos podem ser estruturados de várias manei¬ 
ras. Três possibilidades comuns são representadas na Figu¬ 
ra 5-2. 0 arquivo na Figura 5-2(a) é uma seqüência de 
bytes não-estruturada. Com efeito, o sistema operacional 


Extensão 

Significado \ 

.bak 

Arquivo de backup 

.c 

Programa fonte em C 

X77 

Programa Fortran 77 

■gif 

Imagem no formato GIF (Graphical Interchange Format, da CompuServe) 

.hlp 

Arquivo de ajuda 

.html 

Documento HTML (HyperText Markup Language) da WWW (World Wide Web) 

.mpg 

Filme codificado com o padrão MPEG 

.0 

Arquivo-objeto (saída de compilador, ainda não linkeditado) 

•PS 

Arquivo PostScript 

.tex 

Entrada para o programa de formatação TEX 

.txt 

Arquivo genérico de texto 

.zip 

Arquivo compactado 


Figura 5-1 Algumas típicas extensões de arquivo. 
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(a) (b) (C) 

Figura 5-2 Três tipos de arquivos, (a) Seqüência de bytes, (b) Seqüência de registros, (c) Árvore. 


não sabe nem se importa com o que está no arquivo. Tudo 
que ele vê são bytes. Qualquer significado deve ser imposto 
por programas no nível do usuário. Tanto o UNIX como o 
MS-DOS utilizam essa abordagem. A propósito, o WINDOWS 
95 utiliza basicamente o sistema de arquivos do MS-DOS, 
com uma pequena adição sintática (p. ex., nomes de ar¬ 
quivo longos). Então, quase tudo dito neste capítulo sobre 
o MS-DOS também se aplica ao WINDOWS 95. O WINDOWS nt, 
porém, é completamente diferente. 

Ter o sistema operacional considerando arquivos como 
nada mais do que seqüèncias de bytes oferece um máximo 
de flexibilidade. Os programas de usuário podem colocar 
qualquer coisa que quiserem em arquivos e nomeá-los de 
qualquer maneira que lhe seja conveniente. O sistema ope¬ 
racional não ajuda, mas também não atrapalha. Para usu¬ 
ários que querem fazer coisas incomuns, este último as¬ 
pecto pode ser muito importante. 

O primeiro passo na estrutura é mostrado na Figura 5- 
2(b). Neste modelo, um arquivo é uma seqüência de regis¬ 
tros de comprimento fixo, cada um com alguma estrutura 
interna. O cerne da idéia de que um arquivo é uma se¬ 
qüência de registros está no fato de que a operação de lei¬ 
tura retorna um registro, e as operações de gravação so- 
brescrevem ou anexam um registro. Antigamente, quando 
reinavam os cartões perfurados de 80 colunas, muitos sis¬ 
temas operacionais baseavam seus sistemas de arquivos em 
arquivos que consistiam em registros de 80 caracteres, que, 
de fato, representavam imagens de cartões. Esses sistemas 
também suportavam arquivos de registros com 132 carac¬ 
teres, que foram projetados para impressoras de linha (que 
nesse tempo eram grandes impressoras de cadeia com 132 
colunas). Os programas liam a entrada em unidades de 80 
caracteres e gravavam em unidades de 132 caracteres, em¬ 
bora os 52 finais pudessem ser espaços, naturalmente. 

Um (antigo) sistema que via arquivos como seqüênci- 
as de registros de comprimento fixo era o CP/M. Ele utili¬ 


zava um registro de 128 caracteres. Hoje em dia, a idéia de 
um arquivo como uma seqüência de registros de compri¬ 
mento fixo foi completamente abandonada, embora um 
dia tenha sido a norma. 

O terceiro tipo de estrutura de arquivos é mostrado na 
Figura 5-2(c). Nessa organização, um arquivo consiste em 
uma árvore de registros, não necessariamente todos do 
mesmo comprimento, cada um contendo um campo-cha¬ 
ve em uma posição fixa no registro. A árvore é classificada 
pelo campo-chave, permitindo localizar rapidamente uma 
chave particular. 

A operação básica aqui não é obter o “próximo" regis¬ 
tro, embora isso também seja possível, mas obter o registro 
com uma chave específica. Para o arquivo do zoológico da 
Figura 5-2 (c), poderia ser solicitado que o sistema obtives¬ 
se o registro cuja chave épotro, por exemplo, sem se preo¬ 
cupar com sua posição exata no arquivo. Além disso, no¬ 
vos registros podem ser adicionados ao arquivo, com o sis¬ 
tema operacional e não com o usuário, decidindo onde co¬ 
locá-los. Esse tipo de arquivo é claramente bem diferente 
dos fluxos de byte não-estruturados utilizados no UNIX e no 
MS-DOS, mas é amplamente utilizado nos mainframes de 
grande porte ainda usados em algum processamento co¬ 
mercial de dados. 

5.1.3 Tipos de Arquivo 

Muitos sistemas operacionais suportam vários tipos de 
arquivos. O UNIX e o MS-DOS, por exemplo, têm arquivos e 
diretórios comuns. O UNIX também tem arquivos de carac¬ 
tere e de bloco especiais. Arquivos comuns são os que con¬ 
têm informações do usuário. Todos os arquivos da Figura 
5-2 são comuns. Diretórios são arquivos de sistema para 
manter a estrutura do sistema de arquivos. Estudaremos 
diretórios a seguir. Arquivos especiais de caractere re¬ 
lacionam-se com a entrada/saída e são utilizados para mo- 
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delar dispositivos de E/S seriais como terminais, impresso¬ 
ras e redes. Arquivos especiais de bloco são utilizados 
para modelar discos. Neste capítulo, estaremos interessa¬ 
dos principalmente em arquivos comuns. 

Arquivos comuns são geralmente arquivos ASCII ou 
arquivos binários. Os arquivos ASCII consistem em linhas 
de texto. Em alguns sistemas, cada linha é terminada por 
um caractere de retorno de carro. Em outros, o caractere 
de quebra de linha é utilizado. Ocasionalmente, ambos são 
exigidos. As linhas não necessitam ser todas do mesmo com¬ 
primento. 

A grande vantagem de arquivos ASCII é que podem ser 
exibidos e impressos como são e podem ser editados com 
um editor de texto comum. Além disso, se um grande nú¬ 
mero de programas utiliza arquivos ASCII para entrada e 
saída, é fácil conectar a saída de um programa à entrada 
de outro, como em canalizações (pipelines ) do shell. (O 
“encanamento” interprocesso não é nada fácil, mas inter¬ 
pretar a informação certamente é, se uma convenção-pa¬ 
drão, como ASCII, for utilizada para expressá-la.) 

Outro tipo são arquivos binários, o que significa sim¬ 
plesmente que eles não são arquivos ASCII. Imprimi-los 


resulta em uma lista incompreensível cheia de. aparente¬ 
mente, lixo aleatório. Normalmente, eles têm alguma es¬ 
trutura interna. 

Por exemplo, na Figura 5-3 (a) vemos um arquivo bi¬ 
nário executável simples, obtido de uma versão anterior do 
UNIX. Embora tecnicamente o arquivo seja somente uma 
seqüência de bytes, o sistema operacional somente execu¬ 
tará um arquivo se tiver o formato adequado. Ele tem cin¬ 
co seções: cabeçalho, texto, dados, bits de realocação e ta¬ 
bela de símbolos. O cabeçalho inicia com o chamado nú¬ 
mero mágico, identificando o arquivo como um arquivo 
executável (para evitar a execução acidental de um arqui¬ 
vo que não tenha esse formato). Então, vêm inteiros de 16 
bits fornecendo os tamanhos das várias partes do arquivo, 
o endereço em que a execução inicia e alguns bits de sina¬ 
lização. Seguindo-se ao cabeçalho estão o texto e dados do 
próprio programa. Estes últimos são carregados na memó¬ 
ria e realocados utilizando os bits de realocação. A tabela 
de símbolos é utilizada para depuração. 

Nosso segundo exemplo de arquivo binário também é 
um arquivo do UNIX. Consiste em uma coleção de procedi¬ 
mentos de biblioteca (módulos) compilados, mas não- 


16 Bits 


Número mágico 


Tamanho de texto 

Tamanho dos dados 

Tamanho de BSS 

Tam. da tab. de símbolos 

Ponto de entrada 

W///////////M. 

Sinalizadores 

; Texto ' 

i Dados t 

i Bits de realocação 

Í Tabela de símbolos 



(a) 



Figura 5-3 (a) Um arquivo executável, (b) Um arquivo. 
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linkeditados. Cada um deles é prefaciado por um cabeça¬ 
lho que informa seu nome, sua data de criação, seu pro¬ 
prietário, seu código de proteção e seu tamanho. Assim 
como com o arquivo executável, os cabeçalhos de módulo 
estão cheios de números binários. Copiá-los para a impres¬ 
sora produziria simplesmente lixo. 

Todo sistema operacional deve reconhecer um tipo de 
arquivo, seu próprio arquivo executável, mas alguns reco¬ 
nhecem mais. 0 antigo sistema TOPS-20 ia tão longe a 
ponto de examinar a data/hora de criação de qualquer ar¬ 
quivo a ser executado. Então, ele localizava o arquivo-fon¬ 
te e via se o fonte tinha sido modificado desde que o biná¬ 
rio foi criado. Se tivesse, automaticamente recompilava o 
fonte. Em termos do UNIX, o programa make foi construí¬ 
do dentro Aoshell. Como as extensões de arquivo eram obri¬ 
gatórias, o sistema operacional poderia dizer qual progra¬ 
ma binário derivava de qual fonte. 

Em uma trilha semelhante, quando um usuário do 
WINDOWS dá um clique duplo em um arquivo, um progra¬ 
ma apropriado é carregado com o arquivo como parâme¬ 
tro. 0 sistema operacional determina qual programa deve 
executar com base na extensão do arquivo. 

Implementar rigidamente esses tipos de arquivos cau¬ 
sa problemas sempre que o usuário faz qualquer coisa que 
os projetistas de sistema não previram. Considere, por exem¬ 
plo, um sistema em que os arquivos de saída do programa 
têm tipo dat (arquivos de dados). Se um usuário escreve 
um formatador de programa que lê um arquivo .pas, trans¬ 
forma-o (p. ex., convertendo-o para um leiaute de alinha¬ 
mento) e, então, grava o arquivo transformado como saí¬ 
da, o arquivo de saída será do tipo dat. Se o usuário tentar 
oferecer isso para o compilador Pascal compilá-lo, o siste¬ 
ma recusará porque tem a extensão errada. As tentativas 
de copiarfile.datpa.ra.file.pas serão rejeitadas pelo sistema 
como inválidas (para proteger o usuário contra erros). 

Embora esse tipo de “interface amigável” possa ajudar 
novatos, ele coloca os usuários experientes contra a parede 
porque eles precisam dedicar um esforço considerável para 
contornar a idéia que o sistema operacional tem sobre o 
que é razoável e o que não é. 



Acesso a Arquivos 


Os sistemas operacionais antigos ofereciam somente um 
tipo de acesso a arquivos: acesso seqüencial. Nesses siste¬ 
mas, um processo poderia ler todos os bytes ou registros de 
um arquivo em ordem, iniciando no começo, mas não po¬ 
deria pular e lê-los fora de ordem. Arquivos seqüenciais 
podem ser retrocedidos, entretanto, podendo, então, ser li¬ 
dos conforme for necessário. Arquivos seqüenciais são con¬ 
venientes quando a mídia de armazenamento é fita mag¬ 
nética, em vez de disco. 

Quando se começou a utilizar discos para armazenar 
arquivos, tornou-se possível ler os bytes, ou registros de um 
arquivo, fora da ordem ou acessar registros por chave, em 
vez de por posição. Os arquivos cujos bytes ou registros po¬ 


dem ser lidos em qualquer ordem são chamados arquivos 
de acesso aleatório. 

Arquivos de acesso aleatório são essenciais para muitos 
aplicativos como, por exemplo, sistemas de banco de da¬ 
dos. Se um cliente de linha aérea telefonar e quiser reser¬ 
var um assento em um determinado vôo, o programa de 
reserva deve ser capaz de acessar o registro desse vôo sem 
primeiro ler os registros de milhares de outros vôos. 

Dois métodos são utilizados para especificar onde ini¬ 
ciar a leitura. No primeiro, cada operação read dá a posi¬ 
ção no arquivo em que deve iniciar a leitura. No segundo, 
uma operação especial, SEEK, é oferecida para configurar a 
posição atual. Depois de um SEEK, o arquivo pode ser lido 
seqüencialmente a partir da posição atual. 

Em alguns antigos sistemas operacionais de mainfra- 
mes , os arquivos são classificados como tendo acesso se¬ 
qüencial ou aleatório no momento em que eles são cria¬ 
dos. Isso permite que o sistema utilize diferentes técnicas 
de armazenamento para as duas classes. Sistemas operaci¬ 
onais modernos não fazem essa distinção. Todos os seus 
arquivos são automaticamente de acesso aleatório. 

5.1.5 Atributos de Arquivos 

Cada arquivo tem um nome e dados. Além disso, todos 
os sistemas operacionais associam outras informações com 
cada arquivo, por exemplo, a data e a hora em que o ar¬ 
quivo foi criado e o tamanho do arquivo. Chamaremos es¬ 
ses itens extras de atributos do arquivo. A lista de atributos 
varia consideravelmente de sistema para sistema. A tabela 
da Figura 5-4 mostra algumas possibilidades, mas tam¬ 
bém existem outras. Nenhum sistema existente tem todas 
essas possibilidades, mas cada uma delas está presente em 
algum sistema. 

Os primeiros quatro atributos relacionam-se com a pro¬ 
teção do arquivo e informam quem pode e quem não pode 
acessá-lo. Todos os tipos de esquemas são possíveis, alguns 
estudados mais adiante. Em alguns sistemas, o usuário deve 
apresentar uma senha para acessar um arquivo, caso em 
que a senha deve ser um dos atributos. 

Os sinalizadores são bits ou campos curtos que contro¬ 
lam ou ativam alguma propriedade específica. Arquivos 
ocultos, por exemplo, não aparecem em listagens de todos 
os arquivos. O sinalizador de arquivo é um bit que monito¬ 
ra se o arquivo foi salvo em backup. 0 programa de ba- 
ckup limpa-o, e o sistema operacional configura-o sempre 
que um arquivo é modificado. Dessa maneira, o programa 
de backup pode dizer quais arquivos precisam ser salvos 
em backup. 0 sinalizador de temporário permite que um 
arquivo seja marcado para exclusão automática quando o 
processo que o criou terminar. 

Os campos de comprimento do registro, de posição e de 
comprimento da chave somente estão presentes em arqui¬ 
vos cujo registros podem ser pesquisados, utilizando uma 
chave. Eles oferecem as informações exigidas para locali¬ 
zar as chaves. 
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Campo 

Significado 

Proteção 

Quem pode acessar 0 arquivo e de que maneira 

Senha 

Senha necessária para acessar 0 arquivo 

Criador 

ld da pessoa que criou 0 arquivo 

Proprietário 

Proprietário atual 

Sinalizador de somente-leitura 

0 para leitura/gravação; 1 para somente leitura 

Sinalizador de oculto 

0 para normal; 1 para não exibir em listagens 

Sinalizador de sistema 

0 para arquivos normais; 1 para arquivo de sistema 

Sinalizador de arquivo 

0 para salvo em backup; 1 para ser salvo em backup 

Sinalizador de ASCI l/binário 

0 para arquivo ASCII; 1 para arquivo binário 

Sinalizador de acesso aleatório 

0 para acesso seqüencial somente; 1 para acesso aleatório 

Sinalizador de temporário 

0 para normal; 1 para excluir 0 arquivo na saída do processo 

Sinalizador de bloqueio 

0 para destravado; não-zero para bloqueado 

Comprimento do registro 

Número de bytes em um registro 

Posição da chave 

Deslocamento da chave dentro de cada registro 

Comprimento da chave 

Número de bytes no campo-chave 

Tempo de criação 

Data e hora em que 0 arquivo foi criado 

Tempo do último acesso 

Data e hora em que 0 arquivo foi acessado pela última vez 

Tempo da última alteração 

Data e hora em que 0 arquivo foi alterado pela última vez 

Tamanho atual 

Número de bytes no arquivo 

Tamanho máximo 

Número de bytes até 0 qual 0 arquivo pode crescer 


Figura 5-4 Alguns possíveis atributos de arquivo. 


Os vários campos de tempo monitoram a data e a hora 
em que o arquivo foi criado, mais recentemente acessado e 
mais recentemente modificado. São úteis para vários pro¬ 
pósitos. Por exemplo, um arquivo-fonte que foi modifica¬ 
do após a criação do arquivo-objeto correspondente preci¬ 
sa ser recompilado. Esses campos oferecem as informações 
necessárias. 

0 tamanho atual informa o tamanho atual do arqui¬ 
vo. Alguns sistemas operacionais de mainframe exigem 
que o tamanho máximo seja especificado quando o arqui¬ 
vo é criado, deixando o sistema operacional reservar a quan¬ 
tidade máxima de armazenamento de antemão. Sistemas 
operacionais de estações de trabalho e computadores pes¬ 
soais são suficientemente inteligentes para prescindir des¬ 
se recurso. 

5.1.6 Operações com Arquivos 

Os arquivos existem para armazenar informações e per¬ 
mitir que estas sejam recuperadas mais tarde. Sistemas di¬ 
ferentes oferecem operações diferentes para permitir arma¬ 
zenamento e recuperação. A seguir, discutimos as chama¬ 
das de sistema mais comuns que se relacionam com ar¬ 
quivos. 


1. CREATE. O arquivo é criado sem dados. O propó¬ 
sito da chamada e' anunciar que 0 arquivo está vin¬ 
do e configurar alguns atributos. 

2. DELETE. Quando 0 arquivo não é mais necessá¬ 
rio, ele precisa ser excluído para liberar espaço em 
disco. Há sempre uma chamada de sistema para 
esse propósito. 

3. OPEN. Antes de utilizar um arquivo, um processo 
deve abri-lo. 0 propósito da chamada OPEN é per¬ 
mitir que 0 sistema transfira os atributos e a lista 
de endereços de disco para a memória principal, 
permitindo acesso rápido em chamadas posterio¬ 
res. 

4. CLOSE. Quando todos os acessos terminaram, os 
atributos e os endereços de disco não são mais ne¬ 
cessários, então, 0 arquivo deve ser fechado para 
liberar espaço interno na tabela. Muitos sistemas 
estimulam isso, impondo um número máximo de 
arquivos abertos em processos. Um disco é grava¬ 
do em blocos, e fechar um arquivo força a grava¬ 
ção dos últimos blocos do arquivo, mesmo que esse 
bloco possa não estar ainda inteiramente cheio. 

5. READ. Os dados são lidos do arquivo. Normalmen- 
te, os bytes provêm da posição atual. 0 chamador 
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deve especificar quantos dados são necessários e 
também deve oferecer um buffer onde colocá-los. 

6. WRITE. Os dados são gravados no arquivo, nova¬ 
mente, em geral, na posição atual. Se a posição 
atual for o fim do arquivo, o tamanho do arquivo 
aumentará. Se a posição atual estiver no meio do 
arquivo, os dados existentes serão sobrescritos e per¬ 
didos para sempre. 

7. APPEND. Essa chamada é uma forma restringida 
de WRITE. Ela somente pode colocar dados no fim 
do arquivo. Os sistemas que oferecem um conjun¬ 
to mínimo de chamadas de sistema, em geral, não 
têm APPEND, mas muitos sistemas oferecem múl¬ 
tiplas maneiras de fazer a mesma coisa e esses sis¬ 
temas, às vezes, a têm. 

8. SEEK. Para arquivos de acesso aleatório, é neces¬ 
sário um método para especificar onde pegar os 
dados. Uma abordagem comum é uma chamada 
de sistema, SEEK, que move o ponteiro da posição 
atual para um lugar específico no arquivo. Depois 
que essa chamada completou-se, os dados podem 
ser lidos a partir dessa posição ou gravados nessa 
posição. 

9. GET ATTRIBUTES. Os processos freqüentemente 
precisam ler atributos de arquivo para fazer seu 
trabalho. Por exemplo, o programa make do UNIX 
é comumente utilizado para gerenciar projetos de 
desenvolvimento de software que consistem em 
muitos arquivos-fonte. Quando make é chamado, 
ele examina os tempos de modificação de todos os 
arquivos-fonte e objeto e organiza-os de acordo 
com o número mínimo de compilações exigidas 
para atualizar tudo. Para fazer seu trabalho, ele 
deve olhar os atributos, especificamente nos tem¬ 
pos de modificação. 

10. SET ATTRIBUTES. Alguns atributos são configu¬ 
ráveis pelo usuário e podem ser alterados depois 
que o arquivo foi criado. Essa chamada de sistema 
torna isso possível. As informações sobre o modo 
de proteção são um exemplo óbvio. A maioria dos 
sinalizadores também entra nessa categoria. 


11. RENAME. Freqüentemente ocorre que um usuá¬ 
rio precisa alterar o nome de um arquivo existen¬ 
te. Essa chamada de sistema torna isso possível. 
Ela não é sempre estritamente necessária, porque 
o arquivo normalmente pode ser copiado para um 
novo arquivo com um novo nome, e o arquivo an¬ 
tigo, então, é excluído. 

5.2 DIRETÓRIOS 

Para organizar arquivos, os sistemas de arquivos nor¬ 
malmente têm diretórios que, em muitos sistemas, tam¬ 
bém são arquivos. Nesta seção, discutiremos diretórios, sua 
organização, suas propriedades e as operações que neles 
podem ser executadas. 

5.2.1 Sistemas Hierárquicos de 
Diretórios 

Um diretório geralmente contém um certo número de 
entradas, uma por arquivo. Uma possibilidade é mostrada 
na Figura 5-5 (a), na qual cada entrada contém o nome do 
arquivo, os atributos do arquivo e os endereços de disco 
onde os dados são armazenados. Outra possibilidade é 
mostrada na Figura 5-5 (b). Aqui, uma entrada de diretório 
armazena o nome de arquivo e um ponteiro para outra 
estrutura de dados onde os atributos e os endereços de dis¬ 
co estão localizados. Ambos os sistemas são comumente 
utilizados. 

Quando um arquivo é aberto, o sistema operacional 
pesquisa seu diretório até encontrar o nome do arquivo a 
ser aberto. Então, ele extrai os atributos e os endereços de 
disco, seja diretamente da entrada de diretório, seja da es¬ 
trutura de dados para qual aponta, e coloca-os em uma 
tabela na memória principal. Todas as subseqüentes refe¬ 
rências ao arquivo utilizam as informações da memória 
principal. 

O número de diretórios varia de sistema para sistema. 
O projeto mais simples é o sistema manter um único dire¬ 
tório que contém todos os arquivos de todos os usuários, 
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j atributos 

correio 

j atributos 

notícias 

i atributos 

1 

trabalho 

1 

j atributos 


(a) (b) 


Estrutura de 
dados contendo 
os atributos 


Figura 5-5 (a) Atributos na entrada de diretório, (b) Atributos em outra parte. 
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como ilustrado na Figura 5-6(a). Se houver muitos usuá¬ 
rios e eles escolherem os mesmos nomes de arquivo (p. ex., 
correio e jogos), os conflitos e a confusão rapidamente tor¬ 
narão o sistema inoperante. Esse modelo de sistema era 
utilizado pelo primeiro sistema operacional de microcom¬ 
putador, mas raramente é visto hoje em dia. 

Um aprimoramento na idéia de ter um único diretório 
para todos os arquivos do sistema é ter um diretório por 
usuário [veja Figura 5-6(b)]. Esse projeto elimina confli¬ 
tos de nome entre usuários, mas não é satisfatório para 
usuários com um grande número de arquivos. É muito 
comum que usuários desejem agrupar seus arquivos de 
maneira lógica. Um professor, por exemplo, talvez tenha 
uma coleção de arquivos que, juntos, formam um livro que 
ele está escrevendo para um curso, uma segunda coleção 
de arquivos contém programas de alunos inscritos em ou¬ 
tro curso, um terceiro grupo de arquivos contém o código 
de um sistema avançado de compilação que ele está cons¬ 
truindo, um quarto grupo contém arquivos com propostas 
de bolsas de estudo, assim como outros arquivos para cor¬ 
reio eletrônico, para pautas de reuniões, para papers que 
ele está escrevendo, para jogos e assim por diante. É neces¬ 
sário algum meio de agrupar tais arquivos de maneira fle¬ 
xível escolhida pelo usuário. 

0 que é necessário é uma hierarquia geral (i. e., uma 
árvore de diretórios). Com essa abordagem, cada usuário 
pode ter tantos diretórios quantos forem necessários, de 
modo que os arquivos podem ser agrupados de maneira 
natural. Essa abordagem é mostrada na Figura 5-6(c). Aqui, 
cada um dos diretóriosd, B eC contidos no diretório-raiz 
pertence a um usuário diferente, dois dos quais criaram 
subdiretórios para projetos em que eles estão trabalhando. 


5-2.2 Nomes de Caminho 

Quando o sistema de arquivos é organizado como uma 
árvore de diretórios, é necessário algum meio de especifi¬ 
car nomes de arquivo. Dois métodos diferentes são comu- 
mente utilizados. No primeiro método, a cada arquivo é 
dado um nome de caminho absoluto que consiste no 
caminho do diretório-raiz até o arquivo. Como exemplo, o 
caminho /usr/ast/mailbox significa que o diretório-raiz 
contêm um subdiretório usr. que, por sua vez, contém um 
subdiretório ast, que contém o arquivo mailbox. Nomes 
absolutos de caminho sempre iniciam no diretório-raiz e 
são únicos. No UNIX, os componentes do caminho são se¬ 
parados por “/”. No MS-DOS, o separador é “\”. No MUITICS 
é “>”. Independentemente do caractere utilizado, se o pri¬ 
meiro caractere do nome de caminho for o separador, en¬ 
tão, o caminho será absoluto. 

O outro tipo de nome é o nome de caminho relativo. 
Esse é utilizado em conjunção com o conceito de dire¬ 
tório de trabalho (também chamado diretório atual). 
Um usuário pode designar um diretório como o diretório 
de trabalho atual, caso em que todos os nomes de caminho 
que não começam no diretório-raiz são interpretados em 
relação ao diretório de trabalho. Por exemplo, se o dire¬ 
tório atual de trabalho for /usr/asi, então, o arquivo cujo 
caminho absoluto é / usr/ast/mailbox pode ser referencia¬ 
do simplesmente como mailbox. Em outras palavras, o 
comando UNIX 

cp /usr/ast/mailbox /usr/ast/mailbox.bak 
e o comando 
cp mailbox mailbox.bak 


□ 


Diretório 


(^) Arquivo 



Figura 5-6 Três projetos de sistema de arquivos, (a) Único diretório compartilhado por todos usuários, (b) Um diretório por usuário, 
(c) Árvore arbitrária por usuário. As letras indicam o diretório ou o proprietário do arquivo. 
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fazem exatamente a mesma coisa se o diretório de traba¬ 
lho é/usr/ast. A forma relativa é freqüentemente mais con¬ 
veniente, mas faz a mesma coisa que a forma absoluta. 

Alguns programas precisam acessar um arquivo espe¬ 
cífico sem considerar qual é o diretório de trabalho. Nesse 
caso, eles sempre devem utilizar nomes absolutos de cami¬ 
nho. Por exemplo, um corretor ortográfico talvez precise 
ler /usr/lib/dictionary para fazer seu trabalho. Ele deve 
utilizar o nome de caminho absoluto nesse caso, pois não 
saberá qual é o diretório de trabalho atual quando for 
chamado. 0 nome de caminho absoluto sempre funciona¬ 
rá, independentemente de qual seja o diretório de traba¬ 
lho. 

Naturalmente, se o corretor ortográfico precisar de um 
número grande de arquivos de / usr/lib , uma abordagem 
alternativa é fazer uma chamada de sistema, alterando seu 
diretório de trabalho para /usr/lib e, então, utilizar somente 
dictionary como o primeiro parâmetro para open. Pelo fato 
de alterar explicitamente o diretório de trabalho, o progra¬ 
ma sabe com certeza em que lugar está na árvore de dire¬ 
tórios, portanto, ele pode utilizar caminhos relativos. 

Na maioria dos sistemas, cada processo tem seu pró¬ 
prio diretório de trabalho, então, quando um processo al¬ 


tera seu diretório de trabalho e mais tarde sai, nenhum 
outro processo é afetado e nenhum rastro da alteração é 
deixado para trás no sistema de arquivos. Assim, é sempre 
perfeitamente seguro para um processo alterar seu dire¬ 
tório de trabalho sempre que for conveniente. Por outro 
lado, se uma biblioteca continuar alterando o diretório de 
trabalho e não restaurá-lo antes de terminar, o restante do 
programa não pode trabalhar, uma vez que sua suposição 
sobre onde ele está agora pode ser inválida. Por essa razão, 
procedimentos de biblioteca raramente alteram o diretório 
de trabalho e quando precisam fazer isso, sempre o restau¬ 
ram antes de retomar. 

A maioria dos sistemas operacionais que suporta um 
sistema de diretórios hierárquico tem duas entradas espe¬ 
ciais em cada diretório, e geralmente pronuncia¬ 
dos “ponto” e “ponto-ponto”. O ponto refere-se ao dire¬ 
tório atual; o ponto-ponto refere-se ao seu pai. Para ver 
como são utilizadas, considere a árvore de arquivos UNIX 
da Figura 5-7. Um certo processo tem /usr/ast como sendo 
seu diretório de trabalho. Ele pode utilizar para subir 
na árvore. Por exemplo, ele pode copiar o arquivo /usr/lib/ 
dictionary para o próprio diretório, utilizando o comando 
áe shell 



Figura 5-7 Uma árvore de diretórios UNIX. 
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cp ../lib/dictionary . 

0 primeiro caminho instrui o sistema a ir para cima (para 
o diretório usr), então, descer para o diretório lib para lo¬ 
calizar o arquivo dictionary. 

0 segundo argumento dá o nome do diretório atual. 
Quando o comando cp obtém um nome de diretório (in¬ 
cluindo ponto) como seu último argumento, ele copia to¬ 
dos os arquivos aí. Naturalmente, uma maneira mais na¬ 
tural de fazer a cópia seria digitar 

cp /usr/lib/dictionary . 

aqui a utilização de pontos poupa o usuário do trabalho de 
digitar dictionary uma segunda vez. 

5.2.3 Operações com Diretórios 

As chamadas de sistema permitidas para gerenciar di¬ 
retórios apresentam mais variação de sistema para sistema 
do que as chamadas de sistema para arquivos. Para dar 
uma idéia do que são e como funcionam, daremos um 
exemplo (tomado do UNIX). 

1. CREATE. Um diretório é criado. Ele está vazio ex¬ 
ceto por ponto e ponto-ponto, que são colocados aí 
automaticamente pelo sistema (ou em alguns ca¬ 
sos, pelo programa mkdir). 

2. DELETE. Um diretório é excluído. Somente um 
diretório vazio pode ser excluído. Um diretório que 
contém somente ponto e ponto-ponto é considera¬ 
do vazio uma vez que esses, normalmente, não 
podem ser excluídos. 

3. OPENDIR. Os diretórios podem ser lidos. Por exem¬ 
plo, para listar todos os arquivos em um diretório, 
um programa de listagem abre o diretório para ler 
o nome de todos os arquivos que ele contém. Antes 
de um diretório poder ser lido, ele deve ser aberto 
de maneira análoga à abertura e à leitura de um 
arquivo. 

4. CLOSEDIR. Quando um diretório foi lido, ele deve 
ser fechado para liberar espaço interno da tabela. 

5. READDIR. Essa chamada retorna a próxima en¬ 
trada em um diretório aberto. Antigamente, era 
possível ler diretórios utilizando a chamada de sis¬ 
tema read normal. Mas essa abordagem tem a 
desvantagem de forçar o programador a conhecer 
e a lidar com a estrutura interna de diretórios. Ao 
contrário, READDIR sempre retorna uma entrada 
em um formato padrão, independentemente de 
qual das possíveis estruturas de diretório está sen¬ 
do utilizada. 

6. RENAME. Sob muitos aspectos, os diretórios são 
simplesmente arquivos e podem ser renomeados 
da mesma maneira como os arquivos. 

7. LINK. Vinculação é uma técnica que permite que 
um arquivo apareça em mais de um diretório. Essa 


chamada de sistema especifica um arquivo exis¬ 
tente e um nome de caminho e cria um vínculo do 
arquivo existente para o nome especificado pelo 
caminho. Assim, o mesmo arquivo pode aparecer 
em múltiplos diretórios. 

8. UNLINK. Uma entrada de diretório é removida. Se 
o arquivo sendo desvinculado está presente em 
apenas um diretório (o caso normal), ele é remo¬ 
vido do sistema de arquivos. Se estiver presente em 
múltiplos diretórios, somente o nome de caminho 
especificado é removido. Os outros permanecem. 
No UNIX, a chamada de sistema para excluir ar¬ 
quivos (discutida anteriormente) é, de fato, UNUNK. 

A lista anterior fornece as chamadas mais importantes, 
mas há algumas outras também para, por exemplo, ge¬ 
renciar as informações de proteção associadas com um di¬ 
retório. 

5.3 IMPLEMENTAÇÃO DO SISTEMA DE 
ARQUIVOS 

Agora é hora de mudar do ponto de vista do usuário do 
sistema de arquivos para o enfoque do implementador. Os 
usuários estão preocupados com a maneira como os ar¬ 
quivos são nomeados, que operações são permitidas neles, 
a aparência que a árvore de diretórios tem e questões de 
interface. Os implementadores estão interessados em como 
arquivos e diretórios são armazenados, em como o espaço 
em disco é gerenciado e em como fazer tudo funcionar efi¬ 
ciente e confiavelmente. Nas seções a seguir, examinare¬ 
mos algumas dessas áreas para ver quais são as questões e 
as opções envolvidas. 

(; 5.5.1 Implementando Arquivos 

Provavelmente a questão mais importante ao imple¬ 
mentar armazenamento de arquivos é monitorar quais blo¬ 
cos de disco acompanham quais arquivos. Vários métodos 
são utilizados em diferentes sistemas operacionais. Nesta 
seção, examinaremos alguns deles. 

Alocação Contígua 

0 esquema mais simples de alocação é armazenar cada 
arquivo como um bloco contíguo de dados no disco. As¬ 
sim, em um disco com blocos de 1K, um arquivo de 50K 
alocaria 50 blocos consecutivos. Esse esquema tem duas 
vantagens significativas. Em primeiro lugar, é simples de 
implementar porque monitorar onde os blocos de um ar¬ 
quivo estão reduz-se a lembrar um número, o endereço de 
disco do primeiro bloco. Em segundo lugar, o desempenho 
é excelente porque o arquivo inteiro pode ser lido do disco 
em uma única operação. 
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A alocação contígua, infelizmente, também tem duas 
desvantagens igualmente significativas. Primeiro, não é 
praticável a menos que o tamanho máximo do arquivo seja 
conhecido no momento em que o arquivo é criado. Sem 
essa informação, o sistema operacional não sabe quanto 
espaço em disco reservar. Entretanto, em sistemas em que 
os arquivos devem ser gravados de uma única tacada, ela 
pode ser utilizada com grande vantagem. 

A segunda desvantagem é a fragmentação do disco que 
resulta dessa política de alocação. É desperdiçado espaço 
que. de outra maneira, talvez pudesse ser utilizado. A com¬ 
pactação de disco normalmente tem um custo proibitivo, 
embora concebivelmente possa ser feita à noite, quando o 
sistema está desocupado. 

Alocação por Lista Encadeada 

O segundo método para armazenar arquivos é manter 
cada um como uma lista encadeada de blocos de disco, 
como mostrado na Figura 5-8. A primeira palavra de cada 
bloco é utilizada como um ponteiro para o seguinte. O res¬ 
to do bloco é para dados. 

Diferentemente da alocação contígua, todos os blocos 
do disco podem ser utilizados nesse método. Nenhum es¬ 
paço é desperdiçado em fragmentação de disco (exceto em 
fragmentação interna no último bloco). Além disso, é sufi¬ 
ciente para a entrada de diretório meramente armazenar o 
endereço de disco do primeiro bloco. O restante pode ser 
encontrado iniciando aí. 

Por outro lado, embora a leitura sequencial de um ar¬ 
quivo seja simples e direta, o acesso aleatório é extrema¬ 
mente lento. Além disso, o espaço de dados em um bloco 
não é mais uma potência de dois porque o ponteiro ocupa 
alguns bytes. Embora não fatal, ter um tamanho peculiar 
é menos eficiente porque muitos programas lêem e gra¬ 
vam em blocos cujo tamanho é uma potência de dois. 


Alocação por Lista Encadeada Utilizando 
um índice 

As duas desvantagens da alocação por lista encadeada 
podem ser eliminadas pegando a palavra de ponteiro de 
cada bloco de disco e colocando-a em uma tabela ou em 
um índice na memória. A Figura 5-9 mostra a aparência 
que tem a tabela para o exemplo da Figura 5-8. Em ambas 
as figuras, temos dois arquivos. 0 arquivo A utiliza os blo¬ 
cos de disco 4, 7, 2, 10 e 12, nessa ordem, e o arquivo B 
utiliza os blocos de disco 6, 3, 11 e 14, nessa ordem. Utili¬ 
zando a tabela da Figura 5 - 9 . podemos iniciar com o bloco 
4 e seguir a cadeia completamente até o fim. O mesmo 
pode ser feito iniciando com o bloco 6. 

Utilizando essa organização, o bloco inteiro está dispo¬ 
nível para dados. Além disso, o acesso aleatório é muito 
mais fácil. Embora a cadeia ainda deva ser seguida para 
localizar-se um dado deslocamento dentro do arquivo, a 
cadeia está inteiramente na memória, portanto, ela pode 
ser seguida sem fazer qualquer referência de disco. Como 
no método anterior, é suficiente que a entrada de diretório 
mantenha um inteiro simples (o número do bloco inicial) 
e ainda seja capaz de localizar todos os blocos, indepen¬ 
dentemente do tamanho do arquivo. O MS-DOS utiliza esse 
método para alocação de disco. 

A desvantagem principal desse método é que a tabela 
inteira deve estar na memória todo o tempo para fazê-lo 
funcionar. Com um disco grande, digamos, 500.000 blocos 
de 1K (500 M), a tabela terá 500.000 entradas, cada uma 
da quais com o mínimo 3 bytes. Para acelerar as consul¬ 
tas, elas devem ser de 4 bytes. Assim, a tabela ocupará 1,5 
ou 2 megabytes todo o tempo dependendo de o sistema ser 
otimizado para espaço ou tempo. Embora o MS-DOS utilize 
esse mecanismo, ele evita tabelas enormes, utilizando blo¬ 
cos grandes (até 32K) em discos grandes. 


Arquivo A 



Bloco 4 7 2 10 12 

físico 


Arquivo B 



Bloco 6 3 11 14 

físico 


Figura 5-8 Armazenando um arquivo como uma lista encadeada de blocos de disco. 
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Bloco 

físico 

0 

1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 




10 

11 

7 


3 

2 



12 

14 

0 


0 



O arquivo A começa aqui 
O arquivo B começa aqui 


Bloco não-utilizado 


Figura 5-9 Alocação por lista encadeada, utilizando uma tabela na memória principal. 


/ Nós-/ ) 

Nosso último método para monitorar quais blocos per¬ 
tencem a quais arquivos é associar com cada arquivo uma 
pequena tabela chamada nó-i (nó de índice), que lista 
os atributos e os endereços de disco dos blocos do arquivo, 
como mostrado na Figura 5-10. 

Os primeiros endereços de disco são armazenados no 
próprio nó-i, então, para arquivos pequenos, todas as in¬ 
formações necessárias estão diretamente no nó-i, que é 
carregado do disco para a memória principal quando o 
arquivo é aberto. Para arquivos maiores, um dos endere¬ 
ços no nó-i é o endereço de um bloco de disco chamado 
bloco indireto simples. Esse bloco contém endereços 
adicionais de disco. Se isso ainda não for suficiente, outro 
endereço no nó-i, chamado bloco indireto duplo, con¬ 
tém o endereço de um bloco que, por sua vez, contém uma 
lista de blocos indiretos simples. Cada um desses blocos 
indiretos simples aponta para algumas centenas de blocos 
de dados. Se isso ainda não for suficiente, um bloco indi¬ 
reto triplo também poderá ser utilizado. 0 UNIX utiliza 
esse esquema. 

<5.3.2 Implementando Diretórios 

Antes de um arquivo poder ser lido, ele deve ser aberto. 
Quando um arquivo é aberto, 0 sistema operacional utili¬ 
za 0 nome de caminho fornecido pelo usuário para locali¬ 
zar a entrada de diretório. A entrada de diretório oferece as 
informações necessárias para localizar os blocos de disco. 
Dependendo do sistema, tais informações podem ser 0 en¬ 


dereço de disco do arquivo inteiro (alocação contígua), 0 
número do primeiro bloco (ambos os esquemas de lista 
encadeada) ou 0 número do nó-i. Em todos os casos, a 
principal função do sistema de diretórios é mapear 0 nome 
ASCII do arquivo para as informações necessárias para lo¬ 
calizar os dados. 

Uma questão intimamente relacionada é onde os atri¬ 
butos devem ser armazenados. Uma possibilidade óbvia é 
armazená-los diretamente na entrada de diretório. Muitos 
sistemas fazem exatamente isso. Para sistemas utilizando 
nós-i, outra possibilidade é armazenar os atributos no nó- 
i, em vez de na entrada de diretório. Como veremos mais 
tarde, esse método tem certas vantagens sobre colocar os 
atributos na entrada de diretório. 

Diretórios no CP/M 

Vamos iniciar nosso estudo de diretórios com um exem¬ 
plo particularmente simples, 0 do CP/M (Golden e Pechu- 
ra, 1986), ilustrado na Figura 5-11. Nesse sistema, há so¬ 
mente um diretório, portanto, tudo 0 que 0 sistema de ar¬ 
quivos precisa fazer para procurar um nome de arquivo é 
pesquisar exclusivamente esse diretório. Quando localiza a 
entrada, ele também tem 0 número de blocos de disco, uma 
vez que eles estão armazenados logo na entrada de dire¬ 
tório, como também todos os atributos. Se um arquivo uti¬ 
liza mais blocos de disco do que os que se ajustam em uma 
entrada, 0 arquivo aloca entradas de diretório adicionais. 

Os campos na Figura 5-11 têm os seguintes significa¬ 
dos. O campo código do usuário monitora qual usuário é 
proprietário do arquivo. Durante uma pesquisa, somente 
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Nó-i 



Figura 5-10 Um nó-i. 


as entradas que pertencem ao usuário atualmente conec¬ 
tado são verificadas. Os próximos dois campos dão o nome 
e a extensão do arquivo. 0 campo grau é necessário por¬ 
que um arquivo maior que 16 blocos ocupa múltiplas en¬ 
tradas de diretório. Esse campo é utilizado para dizer qual 
entrada vem em primeiro, em segundo lugar e assim por 
diante. 0 campo contagem de blocos diz quantas das 16 
possíveis entradas de bloco de disco estão em utilização. Os 
16 campos finais contêm os próprios números de bloco de 
disco. 0 último bloco pode não estar cheio, então, o siste¬ 
ma não tem como determinar o tamanho exato de um ar¬ 
quivo até o último byte (i. e., ele monitora tamanhos de 
arquivo em blocos, não em bytes). 

Diretórios no MS-DOS 

Agora vamos considerar alguns exemplos de sistemas 
com árvores de diretório hierárquicas. A Figura 5-12 mos¬ 
tra uma entrada de diretório do MS-DOS. Ela tem 32 bytes 


de comprimento e contém o nome do arquivo, os atributos 
e o número do primeiro bloco de disco. 0 número do pri¬ 
meiro bloco é utilizado como um índice em uma tabela do 
tipo da Figura 5-9- Seguindo a cadeia, todos os blocos po¬ 
dem ser localizados. 

No MS-DOS, os diretórios podem conter outros diretóri¬ 
os, conduzindo a um sistema de arquivos hierárquico. É 
comum no MS-DOS que diferentes programas aplicativos 
iniciem criando um diretório no diretório raiz e colocando 
todos seus arquivos aí, para não haver conflito com aplica¬ 
tivos diferentes. 

Diretórios no UNIX 

A estrutura de diretórios tradicionalmente utilizada no 
UNIX é extremamente simples, como mostrado na Figura 
5-13- Cada entrada contém apenas um nome de arquivo e 
o número de seu nó-i. Todas as informações sobre o tipo, 
tamanho, tempos, proprietário e blocos de disco estão con- 


Bytes 1 


1 2 


-16- 


Nome do arquivo 


I j lj t///A ■ 

7/1 


Números de blocos de disco 
Código do Tipo do arquivo Grau Contagem 
usuário (extensão) de blocos 


Figura 5-11 Uma entrada de diretório que contém os números de bloco de disco para cada arquivo. 
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bloco 


Figura 5-12 Entrada de diretório no MS-DOS. 


tidas no nó-i. Alguns sistemas UNIX têm um arranjo dife¬ 
rente, mas em todos os casos, uma entrada de diretório con¬ 
tém em última instância apenas uma string ASCII e um 
número de nó-i. 

Quando um arquivo é aberto, o sistema de arquivos deve 
pegar o nome de arquivo fornecido e localizar seus blocos 
de disco. Vamos considerar como o nome de caminho / 
usr/ast/mbo.x é localizado. Utilizaremos UNIX como um 
exemplo, mas o algoritmo é basicamente o mesmo para 
todos os sistemas de diretório hierárquicos. Primeiro o sis¬ 
tema de arquivos localiza o diretório-raiz. No UNIX, seu nó- 
i está localizado em um lugar fixo no disco. 

Então, o sistema de arquivos busca o primeiro compo¬ 
nente do caminho, usr, no diretório-raiz para localizar o 
úmero de nó-i do arquivo /usr. Localizar um nó-i a partir 
de seu número é simples e direto, uma vez que cada um 
tem uma posição fixa no disco. A partir desse nó-i, o siste¬ 
ma localiza o diretório para /usr e pesquisa nele o próxi¬ 
mo componente, ast. Quando encontrar a entrada para ast, 
o sistema terá o nó-i para o diretório /usr/ast. A partir des¬ 
se nó-i, o sistema pode localizar o diretório em si e pesqui¬ 
sa mbox. O nó-i para esse arquivo, então, é lido na memó¬ 
ria e mantido aí até o arquivo ser fechado. O processo de 
pesquisa é ilustrado na Figura 5-14. 

Nomes de caminho relativos são pesquisados da mes¬ 
ma maneira que os absolutos, exceto que iniciam a partir 
do diretório de trabalho em vez de iniciar a partir do dire- 
tório-raiz. Cada diretório tem entradas para e que 
são colocados aí quando o diretório é criado. A entrada 
tem o número de nó-i para o diretório atual, e a entrada 
para tem o número de nó-i para o diretório-pai. Assim, 
um procedimento procurando por ../dick/prog.c simples¬ 
mente pesquisa no diretório de trabalho, localiza o 


número de nó-i do diretório-pai e busca por dick nesse di¬ 
retório. Nenhum mecanismo especial é necessário para tra¬ 
tar esses nomes. No que diz respeito ao sistema de dire¬ 
tório, eles são simplesmente cadeias de caracteres ASCII, 
como quaisquer outros nomes. 

5-3.3 Gerenciamento de Espaço em 
Disco 

Os arquivos normalmente são armazenados em disco, 
portanto, 0 gerenciamento de espaço em disco é uma ques¬ 
tão importante para projetistas de sistema de arquivos. Duas 
estratégias gerais são possíveis para armazenar um arqui¬ 
vo de n bytes: os n bytes consecutivos de espaço em disco 
são alocados ou 0 arquivo é dividido em um número de 
blocos (não necessariamente) contíguos. As mesmas esco¬ 
lhas devem ser feitas em sistemas de gerenciamento de 
memória entre segmentação pura e paginação. 

Armazenar um arquivo como uma seqüência contígua 
de bytes tem 0 problema óbvio de que, se um arquivo cres¬ 
cer, ele provavelmente precisará ser movido no disco. 0 
mesmo problema aplica-se a segmentos na memória, ex¬ 
ceto que mover um segmento na memória é uma opera¬ 
ção relativamente rápida se comparada com mover um 
arquivo de uma posição no disco para outra. Por essa ra¬ 
zão, quase todos os sistemas dividem os arquivos em blo¬ 
cos de tamanho fixo que não precisam ser adjacentes. 

Tamanho de Bloco 

Uma vez que foi decidido armazenar arquivos em blo¬ 
cos de tamanho fixo, surge a pergunta de qual tamanho 0 
bloco deve ter. Dada a maneira como os discos são organi- 


Bytes 2 14 


Nome do arquivo 


Número do 
nó-i 


Figura 5-13 Uma entrada de diretório no UNIX. 
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Diretório-raiz 
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bin 
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dev 
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lib 
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etc 
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usr 

8 

tmp 


Procura por usr 
resulta no nó-i 6 


O nó-i 6 
é para /usr 


Modo 

Tamanho 

Tempos 


132 


O nó-i 6 informa 
que /usr está no 
bloco 132 


O bloco 132 é 
o diretório /usr 


6 

• 

1 

' * 

19 

dick 

30 

erik 

51 

jim 

26 

ast 

45 

bal 


/usr/ast é 
o nó-i 26 


O nó-i 26 é 
para /usr/ast 


Modo 

Tamanho 

Tempos 


406 


O nó-i 26 diz 
que /usr/ast está 
no bloco 406 


Bloco 406 é 
o diretório de 
/usr/ast 


26 

• 

6 

•• 

64 

bolsas 

92 

livros 

60 

mbox 

81 

minix 

17 

src 


/usr/ast/mbox 
é o nó-i 60 


Figura 5-14 Os passos ao pesquisar /usr/ast/mbox. 


zados, o setor, a trilha e o cilindro são candidatos óbvios 
para a unidade de alocação. Em um sistema com pagina¬ 
ção, o tamanho da página é também um competidor im¬ 
portante. 

Ter uma unidade grande de alocação, como um cilin¬ 
dro, significa que cada arquivo, mesmo um arquivo de 1 
byte, ocupa um cilindro inteiro. Estudos (Mullender e Ta- 
nenbaum, 1984) demostraram que o tamanho médio de 
arquivo em ambientes UNIX está por volta de 1K, então, alo¬ 
car um cilindro de 32K para cada arquivo desperdiçaria 
31/32 ou 97% do espaço total em disco. Por outro lado, 
utilizar uma unidade de alocação pequena significa que 
cada arquivo consistirá em muitos blocos. A leitura de cada 
bloco normalmente exige uma busca e um atraso rotacio- 
nal, portanto, ler um arquivo consistindo em muitos blo¬ 
cos pequenos é lento. 


Como um exemplo, considere um disco com 32.768 
bytes por trilha, um tempo de rotação de l6,67ms e um 
tempo de busca médio de 30ms. 0 tempo em milissegun- 
dos para ler um bloco de k bytes é, então, a soma dos tem¬ 
pos de busca, de atraso rotacional e transferência: 

30 + 8,3 + {k / 32768) x 16,67 

A curva sólida da Figura 5-15 mostra a taxa de dados 
para tal disco como uma função do tamanho de bloco. Se 
fizermos a suposição grosseira de que todos os arquivos têm 
1K (0 tamanho médio medido), a curva tracejada dessa 
figura dá a eficiência do espaço em disco. A má notícia é 
que a boa utilização de espaço (tamanho de bloco < 2K) 
significa taxas de dados baixas e vice-versa. A eficiência de 
tempo e de espaço estão inerentemente em conflito. 
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Figura 5-15 A curva sólida (escala da esquerda) fornece a taxa de transferência de dados de um disco. A curva tracejada (escala da 
direita) fornece a eficiência do espaço em disco. Todos os arquivos são de 1K. 
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0 ajuste normal é escolher um tamanho de bloco de 
512, 1K ou 2K bytes. Se um tamanho de bloco de 1K for 
escolhido em um disco com um tamanho de setor de 512 
bytes, então, o sistema de arquivos sempre lerá ou gravará 
dois setores consecutivos e irá tratá-los como uma única 
unidade indivisível. Qualquer que seja a decisão tomada, 
provavelmente ela deve ser reavaliada periodicamente, uma 
vez que, como com todos aspectos da tecnologia de com¬ 
putador, os usuários tiram proveito dos recursos mais abun¬ 
dantes, exigindo cada vez mais. Um gerenciador de siste¬ 
ma informa que o tamanho me'dio de arquivos no sistema 
de uma universidade que ele gerencia aumentou lentamen¬ 
te com os anos e que em 1997, o tamanho médio de arqui¬ 
vos cresceu para 12K, no caso dos alunos, e para 15K, no 
caso dos profissionais e dos professores da faculdade. 

Monitorando Blocos Livres 

Uma vez que um tamanho de bloco foi escolhido, a pró¬ 
xima questão é como monitorar blocos livres. Dois méto¬ 
dos são amplamente utilizados, como mostrado na Figura 
5-16. 0 primeiro consiste em utilizar uma lista encadeada 
de blocos de disco, com cada bloco armazenando tantos 
quantos números livres de bloco de disco couberem. Com 
um bloco de 1K e um número de bloco de disco de 32 bits, 
cada bloco na lista de livres armazena os números de 255 
blocos livres. (Uma entrada é necessária para o ponteiro 


para o próximo bloco). Um disco de 200MB necessita de 
uma lista de livres de no máximo 804 blocos para armaze¬ 
nar todos os 200K números de bloco de disco. Blocos livres 
freqüentemente são utilizados para armazenar a lista de 
livres. 

A outra técnica de gerenciamento de espaço livre é o 
mapa de bits. Um disco com n blocos requer um mapa de 
bits com n bits. Blocos livres são representados por ls no 
mapa, e blocos alocados por Os (ou vice-versa). Um disco 
de 200MB requer 200K bits para o mapa, o que requer so¬ 
mente 25 blocos. Não é de surpreender que o mapa de bits 
exija menos espaço, uma vez que utiliza 1 bit por bloco, 
versus 32 bits no modelo de lista encadeada. Somente se o 
disco estiver quase cheio é que o esquema de lista encade¬ 
ada irá requerer menos blocos que o mapa de bits. 

Se houver memória principal suficiente para armaze¬ 
nar o mapa de bits, esse método é geralmente preferível. 
Se, entretanto, somente 1 bloco de memória puder ser dis¬ 
pensado para monitorar blocos livres no disco e o disco 
estiver quase cheio, então, a lista encadeada pode ser me¬ 
lhor. Com somente 1 bloco de mapa de bits na memória, é 
possível que nenhum bloco livre possa ser encontrado, fa¬ 
zendo com que acessos de disco adicionais sejam necessá¬ 
rios para ler o restante do mapa de bits. Quando um bloco 
novo da lista encadeada é carregado na memória, 255 blo¬ 
cos de disco podem ser alocados antes de ir-se para o disco 
a fim de buscar o próximo bloco da lista. 


Blocos de disco livres: 16, 17, 18 


Um bloco de disco de 1K pode 
armazenar 256 números de 
bloco de disco de 32 bits 
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Um mapa de bits 


(a) 


(b) 


Figura 5-16 (a) Armazenando a lista de livres em uma lista encadeada, (b) Um mapa de bits. 
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5-3.4 Confiabilidade do Sistema de 
Arquivos 

A destruição de um sistema de arquivos é frequente¬ 
mente um desastre muito maior do que a destruição de 
um computador inteiro. Se um computador é destruído por 
fogo, oscilações em virtude de relâmpagos ou uma xícara 
de café derramada sobre o teclado, isso é irritante e custará 
dinheiro, mas geralmente uma peça de reposição pode ser 
adquirida com um mínimo de problemas. Computadores 
pessoais baratos podem até ser substituídos dentro de algu¬ 
mas horas com uma simples visita à revenda de produtos 
de informática mais próxima (exceto nas universidades, 
onde fazer um pedido de compra exige três comitês, cinco 
assinaturas e 90 dias). 

Se um sistema de arquivos do computador é irrevoga- 
velmente perdido, seja devido a hardware, software ou a 
ratos que roeram os disquetes, restaurar todas as informa¬ 
ções será difícil, consumirá tempo e, em muitos casos, será 
impossível. Para pessoas cujos programas, documentos, 
arquivos de clientes, registros de impostos, bancos de da¬ 
dos, planos de marketing ou outros dados perderam-se para 
sempre, as consequências podem ser catastróficas. Embora 
o sistema de arquivos não possa oferecer qualquer prote¬ 
ção contra destruição física do equipamento e da mídia, 
ele pode ajudar a proteger as informações. Nesta seção, ve¬ 
remos algumas questões envolvidas na salvaguarda do sis¬ 
tema de arquivos. 

Os discos podem ter blocos defeituosos, como indica¬ 
mos no Capítulo 3- Os disquetes geralmente estão perfeitos 
quando deixam a fábrica, mas podem desenvolver blocos 
defeituosos durante a utilização. Os discos Winchester fre¬ 
quentemente têm blocos defeituosos logo de início: é sim¬ 
plesmente muito caro fabricá-los completamente livres de 
todos os defeitos. De fato, discos rígidos mais antigos cos¬ 
tumavam ser fornecidos com uma lista dos blocos defeitu¬ 
osos descobertos pelos testes do fabricante. Nesses discos, 
um setor é reservado para uma lista de blocos defeituosos. 
Quando a controladora é inicializada pela primeira vez, 
ela lê a lista de blocos defeituosos e seleciona um bloco (ou 
trilha) sobressalente para substituir os defeituosos, regis¬ 
trando o mapeamento na lista de blocos defeituosos. Daí 
em diante, todas as solicitações para o bloco defeituoso uti¬ 
lizarão o sobressalente. Quando novos erros forem desco¬ 
bertos, essa lista é atualizada como parte de uma formata¬ 
ção de baixo nível. 

Houve uma melhora constante nas técnicas de fabrica¬ 
ção, assim os blocos defeituosos são menos comuns que 
antigamente. Entretanto, eles ainda ocorrem. A controla¬ 
dora em uma unidade moderna de disco é muito sofistica¬ 
da, como observado no Capítulo 3- Nesses discos, as trilhas 
têm pelo menos um setor a mais que o necessário, de modo 
que pelo menos um trecho defeituoso pode ser pulado, dei¬ 
xando-o em uma lacuna entre dois setores consecutivos. 
Há também alguns setores sobressalentes por cilindro, por¬ 
tanto, a controladora pode fazer remapeamento automáti¬ 
co do setor se notar que um setor precisa de mais que um 


certo número de tentativas para ser lido ou gravado. Assim, 
o usuário normalmente não está ciente dos blocos defeitu¬ 
osos ou de seu gerenciamento. Contudo, quando uma IDE 
moderna ou disco de SCSI falha, normalmente falhará de 
maneira catastrófica, porque os setores sobressalentes es¬ 
gotam-se. Os discos SCSI oferecem um aviso de “erro recu¬ 
perado” ao remapear um bloco. Se o driver perceber isso e 
imprimir uma mensagem no console, o usuário saberá que 
é hora de comprar um novo disco quando essas mensa¬ 
gens começarem a aparecer com freqüência. 

Há uma solução simples de software para o problema 
de bloco defeituoso, adequada para utilização em discos 
mais antigos. Essa abordagem requer que o usuário ou o 
sistema de arquivos construa com cuidado um arquivo que 
contenha todos os blocos defeituosos. Essa técnica remove- 
os da lista de livres, então, eles nunca ocorrerão em arqui¬ 
vos de dados. Contanto que o arquivo de blocos defeituosos 
nunca seja lido ou gravado, nenhum problema surgirá. 
Cuidado precisa ser tomado durante backups de disco para 
evitar a leitura desse arquivo. 

Backups 

Mesmo com uma estratégia inteligente para lidar com 
blocos defeituosos, é importante fazer backup dos arquivos 
freqüentemente. Afinal de contas, alternar automaticamen¬ 
te para uma trilha sobressalente depois que blocos de da¬ 
dos cruciais foram arruinados é algo parecido como fe¬ 
char a porta do celeiro depois que o cavalo de raça premi¬ 
ado escapou. 

Os sistemas de arquivos em disquete podem ser salvos 
em backup simplesmente copiando o disquete inteiro para 
um em branco. Os sistemas de arquivos em discos Winches¬ 
ter pequenos podem ser salvos em backup fazendo cópia 
do disco inteiro para fita magnética. Tecnologias atuais 
incluem cartuchos de fita de 150 M e fitas Exabyte ou DAT 
de 8 G. 

Para winchesters grandes (p. ex., de 10 GB), fazer ba¬ 
ckup da unidade inteira em fita é um incômodo e conso¬ 
me tempo. Uma estratégia que é fácil de implementar, mas 
desperdiça metade do armazenamento é oferecer a cada 
computador duas unidades em vez de uma. Ambas as uni¬ 
dades são divididas em duas metades: dados e backup. Cada 
noite, a parte de dados da unidade 0 é copiada para a parte 
de backup da unidade 1 e vice-versa, como mostrado na 
Figura 5-17. Dessa maneira, se uma unidade for comple¬ 
tamente arruinada, nenhuma informação será perdida. 

Uma alternativa para fazer a cópia do sistema de ar¬ 
quivos inteiro todo dia são as cópias incrementais. A for¬ 
ma simples de fazer uma cópia incremental é fazer uma 
cópia completa periodicamente, digamos, semanalmente 
ou mensalmente, e fazer uma cópia diária somente dos 
arquivos que foram modificados desde a última cópia com¬ 
pleta. Um esquema melhor é copiar somente os arquivos 
alterados desde que eles foram copiados pela última vez. 

Para implementar esse método, uma lista dos tempos 
de cópia para cada arquivo deve ser mantida no disco. O 
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Figura 5-17 Fazer backup de uma unidade em outra desperdiça metade do espaço de armazenamento. 


programa de cópia, então, verifica cada arquivo no disco. 
Se esse foi modificado desde a última cópia, ele é copiado 
novamente e seu tempo de última cópia é alterado para o 
tempo atual. Se feito em um ciclo mensal, esse método re¬ 
quer 31 fitas diárias de cópia, uma por dia, mais as fitas 
suficientes para armazenar uma cópia completa, feita uma 
vez por mês. Outros esquemas mais complexos que utili¬ 
zam menos fitas também estão em utilização. 

Métodos automáticos que utilizam múltiplos discos 
também são utilizados. Por exemplo, o espelhamento uti¬ 
liza dois discos. Gravações vão para ambos os discos, e lei¬ 
turas vêm de um. A gravação para o disco de espelho é atra¬ 
sada um pouco, de modo que possa ser feita quando o sis¬ 
tema esteja desocupado. Um sistema assim pode continuar 
a executar em “modo degradado” quando um disco falha, 
permitindo que um disco defeituoso seja substituído, e os 
dados sejam recuperados sem parada do sistema. 

( Consistência do Sistema de Arquivos 

Outra área onde a confiabilidade é uma questão é a 
consistência do sistema de arquivos. Muitos sistemas de 
arquivos lêem blocos, modificam-nos e gravam-nos mais 
tarde. Se o sistema cai antes de todos os blocos modificados 
serem gravados, o sistema de arquivos pode ser deixado em 
um estado inconsistente. Esse problema é especialmente 
crítico se alguns blocos que não foram gravados forem blo¬ 
cos de nó-i, blocos de diretório ou blocos contendo a lista 
de livres. 

Para lidar com o problema de sistemas de arquivos in¬ 
consistentes, a maioria dos computadores tem um progra¬ 
ma utilitário que verifica a consistência do sistema de ar¬ 
quivos. Ele pode ser executado sempre que o sistema é ini- 
cializado, especialmente depois de uma queda. A descrição 
a seguir diz como esse utilitário funciona no UNIX e no 
MINIX; outros sistemas têm algo semelhante. Esses verifica¬ 
dores de sistema de arquivos verificam cada sistema de ar¬ 
quivos (disco) independentemente dos demais. 

Dois tipos de verificação de consistência podem ser fei¬ 
tos: blocos e arquivos. Para verificar consistência de blo¬ 
cos, o programa constrói duas tabelas, cada uma contendo 


um contador para cada bloco, inicialmente configurado 
como 0. Os contadores na primeira tabela monitoram quan¬ 
tas vezes cada bloco está presente em um arquivo; os con¬ 
tadores na segunda tabela registram a freqüência com que 
cada bloco está presente na lista de livres (ou no mapa de 
bits de blocos livres) 

O programa, então, lê todos os nós-i. Iniciando de um 
nó-i, é possível construir uma lista de todos os números de 
bloco utilizados no arquivo correspondente. À medida que 
cada número de bloco é lido, seu contador na primeira ta- ] 
bela é incrementado. O programa, então, examina a lista j 
de livres ou de mapa de bits, para localizar todos os blocos j 
que não estão em utilização. Cada ocorrência de um bloco ] 
na lista de livres resulta no incremento do seu contador na 
segunda tabela. 

Se o sistema de arquivos é consistente, cada bloco terá 
1 na primeira tabela ou na segunda tabela, como ilustrado 
na Figura 5-18(a). Entretanto, como um resultado de uma 
queda, as tabelas talvez se pareçam com a Figura 5-18(b), 
na qual os blocos 2 não ocorrem em nenhuma tabela. Ele 
será informado como sendo um bloco ausente. Embora 
os blocos ausentes não causem nenhum dano real, eles 
desperdiçam espaço e, portanto, reduzem a capacidade do 
disco. A solução para blocos ausentes é simples e direta: o 
verificador do sistema de arquivos simplesmente adiciona- 
os à lista livre. 

Outra situação que talvez ocorra é a da Figura 5-18(c). 
Aqui vemos um bloco, número 4, que ocorre duas vezes na 
lista de livres. (Duplicatas podem ocorrer somente se a lis¬ 
ta de livres for realmente uma lista; com um mapa de bits 
é impossível.) A solução aqui também é simples: recons¬ 
truir a lista de livres. 

A pior coisa que pode acontecer é o mesmo bloco de 
dados estar presente em dois ou mais arquivos, como mos¬ 
trado na Figura 5-18(d) com o bloco 5. Se qualquer um 
desses arquivos for removido, o bloco 5 será colocado na 
lista de livres, o que leva a uma situação em que o mesmo 
bloco está tanto em utilização como livre ao mesmo tem¬ 
po. Se os dois arquivos forem removidos, o bloco será colo¬ 
cado na lista de livres duas vezes. 
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Figura 5-18 Estados do sistema de arquivos, (a) Consistente, (b) Bloco ausente, (c) Bloco duplicado na lista livre, (d) Bloco de dados 
duplicado. 


A ação apropriada para o verificador de sistema de ar¬ 
quivos tomar é alocar um bloco livre, copiar o conteúdo do 
bloco 5 nele e inserir a cópia em um dos arquivos. Assim, o 
conteúdo das informações dos arquivos permanece inalte¬ 
rado (embora quase seguramente embaralhado), mas pelo 
menos a estrutura do sistema de arquivos é tornada consis¬ 
tente. O erro deve ser informado, permitindo que o usuário 
inspecione o dano. 

Além de verificar se cada bloco está adequadamente 
contabilizado, o verificador do sistema de arquivos tam¬ 
bém verifica o sistema de diretórios. Ele também utiliza 
uma tabela de contadores, mas esses são por arquivo, em 
vez de por bloco. Ele inicia no diretório-raiz e recursiva¬ 
mente desce a árvore, inspecionando cada diretório no sis¬ 
tema de arquivos. Para cada arquivo em cada diretório, ele 
incrementa o contador para o nó-i desse arquivo (veja a 
Figura 5-13 para o arranjo de uma entrada de diretório). 

Quando tudo está feito, ele tem uma lista, indexada por 
número de nó-i, dizendo quantos diretórios apontam para 
esse nó-i. Então, ele compara esses números com a conta 
de vínculos armazenada nos próprios nós-i. Em um siste¬ 
ma de arquivos consistente, as duas contagens coincidi¬ 
rão. Entretanto, dois tipos de erro podem ocorrer: a conta¬ 
gem de vínculos no nó-i pode ser muito alta ou muito baixa. 

Se a contagem de vínculos é mais alta do que o número 
de entradas de diretório, então, mesmo se todos os arquivos 
forem removidos dos diretórios, a contagem ainda será não- 
zero e o nó-i não será removido. Esse erro não é sério, mas 
desperdiça espaço no disco com arquivos que não estão em 
nenhum diretório. Isso deve ser corrigido, configurando-se 
a contagem de vínculos no nó-i com o valor correto. 

O outro erro é potencialmente catastrófico. Se duas en¬ 
tradas de diretório estão vinculadas a um arquivo, mas o 
nó-i diz que há somente uma, quando qualquer uma das 
entradas de diretório for removida, a contagem do nó-i irá 
zerar. Quando a contagem do nó-i chega a zero, o sistema 
de arquivos marca-o como não-utilizado e libera todos os 


seus blocos. Essa ação fará com que um dos diretórios ago¬ 
ra aponte para um nó-i não-utilizado, cujos blocos seguin¬ 
tes podem ser atribuídos a outros arquivos. Novamente, a 
solução é simplesmente forçar a contagem de vínculos no 
nó-i para o número real de entradas de diretório. 

Essas duas operações, verificar blocos e verificar dire¬ 
tórios, freqüentemente são integradas por razões de efici¬ 
ência (i. e., somente uma passagem sobre os nós-i é exigi¬ 
da). Outra verificações heurísticas são também possíveis. 
Por exemplo, os diretórios têm um formato definido, com 
números de nó-i e nomes ASCII. Se um número de nó-i for 
maior que o número de nós-i no disco, o diretório foi dani¬ 
ficado. 

Além disso, cada nó-i tem um modo, alguns dos quais 
são válidos, mas estranhos, como 0007, que não concede 
ao proprietário e a seu grupo absolutamente nenhum aces¬ 
so, mas permite que estranhos leiam, gravem e executem o 
arquivo. Talvez seja útil pelo menos informar sobre arqui¬ 
vos que dão a estranhos mais direitos do que ao proprietá¬ 
rio. Os diretórios com mais que, digamos, 1.000 entradas 
também são suspeitos. Arquivos localizados em diretórios 
de usuário, mas que são possuídos pelo superusuário e tem 
o bit de SETUID ativado, são problemas de segurança po¬ 
tenciais. Com um pequeno esforço, pode-se montar uma 
lista relativamente longa de situações legais, mas peculia¬ 
res, que talvez mereçam um informe. 

Os parágrafos anteriores discutiram o problema de pro¬ 
teger o usuário contra quedas. Alguns sistemas de arquivos 
também preocupam-se em proteger o usuário contra si pró¬ 
prio. Se o usuário pretender digitar 

rm *. o 

para remover todos os arquivos que terminam com .o (ar¬ 
quivos-objeto gerados pelo compilador), mas acidental¬ 
mente digitar 

rm * .o 
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(note o espaço depois do asterisco), rm removerá todos os 
arquivos no diretório atual e, então, irá queixar-se que não 
pôde localizar . 0 . No MS-DOS e em alguns outros sistemas, 
quando um arquivo é removido, tudo 0 que acontece e' que 
um bit é configurado no diretório ou no nó-i, marcando 0 
arquivo como removido. Nenhum bloco de disco e' retor¬ 
nado à lista de livres até que eles realmente sejam necessá¬ 
rios. Assim, se 0 usuário descobre 0 erro imediatamente, é 
possível executar um programa especial utilitário que “de- 
sexclui” (i. e., restaura) os arquivos removidos. No WINDO¬ 
WS 95, arquivos que são removidos são colocados em um 
diretório especial recycled (lixeira), do qual eles podem 
ser recuperados mais tarde se necessário. Naturalmente, 
nenhum armazenamento é reivindicado até que eles se¬ 
jam realmente excluídos desse diretório. 

-5>3.5 Desempenho do Sistema de 
Arquivos 

0 acesso a disco é muito mais lento que 0 acesso à me¬ 
mória. A leitura de uma palavra da memória geralmente 
leva dezenas de nanossegundos. A leitura de um bloco de 
um disco rígido pode levar 50 microssegundos, um fator 
quatro vezes mais lento por palavra de 32 bits, mas a isso 
deve ser adicionado 10 a 20 milissegundos para buscar a 
trilha e, então, esperar 0 setor desejado chegar sob 0 cabe¬ 
çote de leitura. Se apenas uma única palavra for necessá¬ 
ria, 0 acesso à memória é da ordem de 100.000 vezes mais 
rápido que 0 acesso a disco. Como um resultado dessa dife¬ 
rença em tempo de acesso, muitos sistemas de arquivos fo¬ 
ram projetados para reduzir 0 número de acessos a disco 
necessários. 

A técnica mais comum utilizada para reduzir acessos a 
disco é 0 cache de bloco ou 0 cache de buffer. (Cache é 
pronunciado como “kàsh”, e deriva do francês cacher, que 
significa ocultar) Nesse contexto, um cache é uma cole¬ 
ção de blocos que logicamente pertencem ao disco, mas 
que estão sendo mantidos na memória por razões de de¬ 
sempenho. 

Vários algoritmos podem ser utilizados para gerenciar 
0 cache, mas um comum é verificar todas as solicitações 
de leitura para ver se 0 bloco necessário está no cache. Se 
estiver, a solicitação de leitura pode ser satisfeita sem aces¬ 
so de disco. Se 0 bloco não estiver no cache, é primeiro lido 
no cache e, então, copiado para qualquer lugar que seja 
necessário. Solicitações subseqüentes para 0 mesmo bloco 
podem ser satisfeitas a partir do cache. 

Quando um bloco precisa ser carregado em um cache 
cheio, algum bloco precisa ser removido e regravado para 
0 disco se foi modificado desde que foi trazido. Essa situa¬ 
ção é muito parecida com a paginação, e todos os algorit¬ 
mos normais de paginação descritos no Capítulo 4, como 
F1FO, segunda chance, e LRU, são aplicáveis. Uma dife¬ 
rença agradável entre paginação e cache é que referências 
de cache são relativamente raras, de modo que é razoável 
manter todos os blocos na ordem exata de LRU com listas 
encadeadas. 


Infelizmente, há uma cilada. Agora que temos uma si¬ 
tuação em que LRU exato é possível, este revela-se indese- 
j ável. O problema tem a ver com as quedas e a consistência 
do sistema de arquivos discutidas na seção anterior. Se um 
bloco crítico, como um bloco de nó-i, é lido no cache e 
modificado, mas não-regravado no disco, uma queda dei¬ 
xará 0 sistema de arquivos em um estado inconsistente. Se 
0 bloco de nó-i tiver sido colocado no fim da cadeia de LRU, 
pode demorar um pouco para alcançar a frente e ser regra¬ 
vado no disco. 

Além disso, alguns blocos, como os indiretos duplos, 
raramente são referenciados duas vezes dentro de um in¬ 
tervalo curto. Essas considerações conduzem a um esque¬ 
ma modificado de LRU, levando em conta dois fatores: 

1. É possível que 0 bloco seja necessário novamente 
em breve? 

2. O bloco é essencial para a consistência do sistema 
de arquivos? 

Para ambas as perguntas, os blocos podem ser divididos 
em categorias como blocos de nó-i blocos indiretos, como 
blocos de diretório, como blocos cheios de dados e blocos 
parcialmente cheios de dados. Os blocos que provavelmen¬ 
te não serão necessários novamente irão na frente, em vez 
de no fim da lista de LRU, portanto, seus buffers serão reu¬ 
tilizados rapidamente. Os blocos que talvez sejam necessá¬ 
rios novamente logo, como um bloco parcialmente cheio 
que está sendo gravado, entram no fim da lista, para que 
permaneçam à mão por bastante tempo. 

A segunda pergunta é independente da primeira. Se 0 
bloco é essencial para a consistência do sistema de arqui¬ 
vos (basicamente, tudo exceto blocos de dados) e foi modi¬ 
ficado, ele deverá ser gravado em disco imediatamente, 
independentemente da extremidade da lista de LRU em que 
ele foi colocado. Gravando blocos críticos com rapidez, re¬ 
duzimos significativamente a probabilidade de que uma 
queda destruirá 0 sistema de arquivos. 

Mesmo com essa medida para manter intacta a inte¬ 
gridade do sistema de arquivos, é indesejável manter blo¬ 
cos de dados no cache por muito tempo antes de gravá-los. 
Considere 0 compromisso de alguém que esteja utilizando 
um computador pessoal para escrever um livro. Mesmo se 
nosso escritor periodicamente instruísse 0 editor para gra¬ 
var no disco 0 arquivo que está sendo editado, há uma boa 
chance de que tudo ainda estará no cache e nada no disco. 
Se 0 sistema cai, a estrutura do sistema de arquivos não 
será corrompida, mas um dia inteiro de trabalho será per¬ 
dido. 

Essa situação não precisa acontecer com muita freqüên- 
cia para termos um usuário insatisfeito. Para lidar com 
ela, os sistemas exigem duas abordagens. A maneira do UNIX 
é ter uma chamada de sistema, SYNC, que força todos os 
blocos modificados a ir para 0 disco imediatamente. Quan¬ 
do 0 sistema é iniciado, um programa, normalmente cha¬ 
mado upclate, é iniciado em segundo plano para perma¬ 
necer em um laço interminável que emite chamadas SYNC, 
dormindo por 30 s entre as chamadas. Como resultado, não 
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mais que 30 segundos de trabalho é perdido devido a uma 
queda. 

A maneira do MS-DOS é gravar em disco cada bloco 
modificado logo que ele foi gravado. Os caches em que to¬ 
dos os blocos modificados são gravados de volta para o dis¬ 
co imediatamente são chamados caches de gravação in¬ 
termediária. Eles exigem muito mais E/S de disco do que 
os outros tipos de cache. A diferença entre essas duas abor¬ 
dagens pode ser vista quando um programa grava um blo¬ 
co de 1K cheio, um caractere por vez. O UNIX reunirá todos 
os caracteres no cache e gravará o bloco no disco uma vez 
a cada 30 segundos ou sempre que o bloco for removido do 
cache. O MS-DOS fará um acesso de disco a cada caractere 
gravado. Naturalmente, a maioria dos programas faz bu- 
ffeiização interna, portanto, eles normalmente não gra¬ 
vam um caractere, mas uma linha ou uma unidade maior 
a cada chamada de sistema write. 

Uma conseqüência dessa diferença nas estrate'gias de 
fazer cache, é que a simples remoção de um disco (disque¬ 
te) de um sistema UNIX sem fazer um SYNC quase sempre 
resultará em dados perdidos e, freqüentemente, em um sis¬ 
tema de arquivos corrompido também. Com o MS-DOS, ne¬ 
nhum problema surge. Essas estratégias diferentes foram 
escolhidas porque o UNIX foi desenvolvido em um ambien¬ 
te em que todos os discos eram discos rígidos e não-remo¬ 
víveis, enquanto o MS-DOS começou com disquetes. À me¬ 
dida que os discos rígidos tornam-se a norma, mesmo em 
microcomputadores pequenos, a abordagem do UNIX, com 
sua melhor eficiência, será definitivamente a maneira re¬ 
comendada e adotada. 

Fazer cache não é a única maneira de aumentar o de¬ 
sempenho de um sistema de arquivos. Outra técnica im¬ 
portante é reduzir o deslocamento do braço de disco, colo¬ 
cando os blocos que podem ser acessados em seqüência 
próximos um do outro, preferivelmente no mesmo cilin¬ 
dro. Quando um arquivo de saída é gravado, o sistema de 
arquivos precisa alocar os blocos um por vez, conforme eles 
sejam necessários. Se os blocos livres são registrados em 
um mapa de bits e o mapa de bits inteiro está na memória 
principal, é muito fácil escolher um bloco livre o mais pró¬ 
ximo possível do bloco anterior. Com uma lista de livres, 
parte da qual está em disco, é muito mais difícil alocar 
blocos próximos ou juntos. 

Entretanto, mesmo com uma lista de livres, alguma 
alocação de bloco contíguos pode ser feita. O truque é mo¬ 
nitorar o armazenamento de disco não em blocos, mas em 
grupos de blocos consecutivos. Se uma trilha consiste em 
64 setores de 512 bytes, o sistema poderia utilizar blocos de 
1K (2 setores), mas alocar armazenamento de disco em 
unidades de 2 blocos (4 setores). Isso não é o mesmo que 
ter um bloco de disco de 2K, uma vez que o cache ainda 
utilizaria blocos de 1K, e as transferências de disco ainda 
seriam de 1K, mas a leitura seqüencial de um arquivo em 
um sistema que, por outro lado, estaria desocupado, redu¬ 
ziria o número de buscas por um fator de dois, melhoran¬ 
do consideravelmente o desempenho. 


Uma variação sobre o mesmo tema é levar em conta o 
posicionamento rotacional. Ao alocar blocos, o sistema ten¬ 
ta colocar blocos consecutivos em um arquivo no mesmo 
cilindro, mas de maneira intercalada para alcançar tan- 
gência máxima. Portanto, se um disco tiver um tempo de 
rotação de l6,67ms e levar aproximadamente 4ms para um 
processo de usuário solicitar e obter um bloco de disco, cada 
bloco deve ser colocado a pelo menos 1/4 da distância até 
seu predecessor. 

Outro gargalo de desempenho em sistemas utilizando 
nós-i ou qualquer coisa equivalente a nós-i, é que mesmo 
a leitura de um arquivo curto requer dois acessos a disco: 
um para o nó-i e um para o bloco. A colocação normal de 
nó-i é mostrada na Figura 5-19(a). Aqui todos os nós-i es¬ 
tão próximos do começo do disco, então, a distância média 
entre um nó-i e seus blocos será a metade do número de 
cilindros, exigindo buscas longas. 

Uma maneira fácil de melhorar o desempenho é colo¬ 
car os nós-i no meio do disco, em vez de no início, redu¬ 
zindo assim a busca média entre o nó-i e o primeiro bloco 
por um fator de dois. Outra idéia, mostrada na Figura5- 
1 9(b), é dividir o disco em grupos de cilindros, cada um 
com seus próprios nós-i, blocos e lista de livres (McKusick 
et ai, 1984). Ao criar um novo arquivo, qualquer nó-i pode 
ser escolhido, mas é feita uma tentativa de localizar um 
bloco no mesmo grupo de cilindros que o nó-i. Se nenhum 
estiver disponível, então, um bloco perto do grupo de cilin¬ 
dros é utilizado. 

5.3.6 Sistemas de Arquivos 
Estruturados em Log 

As mudanças na tecnologia estão exercendo uma pres¬ 
são nos sistemas de arquivos atuais. Em particular, as CPUs 
ficam cada vez mais rápidas, os discos estão tomando-se 
cada vez maiores e mais baratos (mas não muito mais rá¬ 
pidos) e as memórias estão crescendo exponencialmente 
em tamanho. O parâmetro que não está melhorando aos 
saltos é o tempo de busca do disco. A combinação desses 
fatores significa que um gargalo de desempenho está sur¬ 
gindo em muitos sistemas de arquivos. Pesquisas feitas em 
Berkeley tentaram aliviar esse problema projetando um tipo 
completamente novo de sistema de arquivos, LFS ( Log- 
Structured File Ags/e/w/Sisteinas de Arquivos Estrutu¬ 
rados em Log). Nesta seção, descreveremos resumidamen¬ 
te como o LFS funciona. Para um tratamento mais com¬ 
pleto, veja (Rosenblum e Ousterhout, 1991). 

A idéia que guiou o projeto do LFS é que, à medida que 
as CPUs ficam mais rápidas, e as memórias RAM ficam 
maiores, os caches de disco tornam-se cada vez mais rápi¬ 
dos. Como conseqüência, agora é possível satisfazer uma 
fração muito substancial de toda solicitação de leitura di¬ 
retamente do cache do sistema de arquivos, sem necessida¬ 
de de acessos a disco. Deduz-se dessa observação que, no 
futuro, a maioria dos acessos de disco será de gravação, 
portanto, o mecanismo de leitura antecipada ( read-ahead ), 



292 TANENBAUM & WOODHULL 


Os nós-i estão O disco é dividido em 

localizados próximos grupos de cilindros cada um 

do início do disco com seus próprios nós-i 



(a) 



Figura 5-19 (a) Nós-i colocados no início do disco, (b) Disco dividido em grupos de cilindros, cada um com seus 

próprios blocos e nós-i. 


utilizado em alguns sistemas de arquivos para buscar blo¬ 
cos antes de eles serem necessários, não mais oferece mui¬ 
to ganho de desempenho. 

Para piorar as coisas, na maioria dos sistemas de ar¬ 
quivos, as gravações são feitas em porções muito peque¬ 
nas. Gravações pequenas são altamente ineficientes, uma 
vez que uma gravação em disco de 50 microssegundos ge¬ 
ralmente é precedida por uma busca de lOms, e um retar¬ 
do rotacional de 6ms. Com esses parâmetros, a eficiência 
de disco cai para uma fração de 1%. 

Para ver de onde provêm todas as gravações pequenas, 
considere a criação de um novo arquivo em um sistema 
UNIX. Para gravar esse arquivo, o nó-i para o diretório, o 
bloco de diretório, o nó-i para o arquivo e o próprio arqui¬ 
vo devem ser todos gravados. Embora essas gravações pos¬ 
sam ser retardadas, fazer isso expõe o sistema de arquivos 
a problemas sérios de consistência se uma queda ocorrer 
antes das gravações terem sido feitas. Por essa razão, as 
gravações de nó-i geralmente são feitas imediatamente. 

A partir desse raciocínio, os projetistas do LFS decidi¬ 
ram reimplementar o sistema de arquivos do UNIX de ma¬ 
neira a alcançar toda a largura de banda do disco, mesmo 
perante uma carga de trabalho que, em grande parte, con¬ 
siste de pequenas gravações aleatórias. A idéia básica é es¬ 
truturar o disco inteiro como um log. Periodicamente e 
quando houver uma necessidade especial, todas as grava¬ 
ções pendentes sendo bufferizadas na memória são cole¬ 
cionadas em um único segmento e gravadas no disco como 
em um único segmento contínuo no fim do log. Um seg¬ 
mento único pode assim conter nós-i, blocos de diretório e 
blocos de dados, todos misturados. No início de cada seg¬ 
mento, está um resumo do segmento, informando o que 
pode ser encontrado no segmento. Se o segmento médio 
pode ser levado a ser de aproximadamente 1MB, quase toda 
a largura de banda do disco pode ser utilizada. 

Nesse projeto, nós-i ainda existem e têm a mesma es¬ 
trutura que no UNIX, mas agora estão dispersos por todo o 


log, em vez de estar em uma posição fixa no disco. Contu¬ 
do, quando um nó-i é localizado, localizar os blocos é feito 
na maneira usual. Naturalmente, localizar um nó-i é ago¬ 
ra muito mais difícil, uma vez que seu endereço simples¬ 
mente não pode ser calculado a partir de seu número i, 
como no UNIX. Para tornar possível localizar nós-i, um 
mapa de nós-i, indexado pelo número i, é mantido. A en¬ 
trada i desse mapa aponta para o nó-i i no disco. O mapa é 
mantido em disco, mas também sofre cache, então, partes 
mais intensamente utilizadas estarão na memória na maior 
parte do tempo. 

Para resumir o que dissemos até agora, todas as grava¬ 
ções são armazenadas na memória e periodicamente todas 
as gravações armazenadas são gravadas no disco em um 
único segmento, no fim do log. A abertura de um arquivo 
agora consiste em utilizar o mapa para localizar o nó-i do 
arquivo. Uma vez que o nó-i foi localizado, os endereços 
dos blocos podem ser localizados a partir dele. Todos os blo¬ 
cos em si estarão em segmentos, em algum lugar no log. 

Se os discos fossem infinitamente grandes, a descrição 
acima encerraria a história. Contudo, os discos reais são 
limitados, então, por fim, o log acaba ocupando o disco 
inteiro, momento em que nenhum novo segmento pode 
ser gravado no log. Felizmente, muitos segmentos existen¬ 
tes podem ter blocos que não são mais necessários, por 
exemplo, se um arquivo é sobrescrito, seu nó-i agora apon¬ 
tará para os novos blocos, mas os antigos ainda estarão 
ocupando espaço nos segmentos anteriormente gravados. 

Para lidar com esses dois problemas, o LFS tem um thre- 
ad limpador que gasta seu tempo varrendo o log circular¬ 
mente para compactá-lo. Ele começa lendo o resumo do 
primeiro segmento no log para ver quais nós-i e quais ar¬ 
quivos estão aí. Então, ele verifica o mapa atual de nós-i 
para ver se os nós-i são ainda atuais e se os blocos de arqui¬ 
vo ainda estão em uso. Se não, as informações são descar¬ 
tadas. Os nós-i e os blocos que ainda estão em uso são tra¬ 
zidos para a memória para serem gravados em disco no 
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próximo segmento. 0 segmento original, então, é marca¬ 
do como livre, portanto, o log pode utilizá-lo para novos 
dados. Dessa maneira, o limpador move-se ao longo do log, 
removendo segmentos antigos do final e colocando quais¬ 
quer dados em uso na memória para regravação no próxi¬ 
mo segmento. Conseqüentemente, o disco é um grande 
buffer circular, com o thread gravador adicionando novos 
segmentos na frente, e os thread limpadores removendo os 
antigos do final. 

A manutenção aqui não é trivial, uma vez que quando 
um bloco de arquivo é gravado de volta em um novo seg¬ 
mento, o nó-i do arquivo (em algum lugar no log) deve ser 
localizado, atualizado e colocado na memória para ser gra¬ 
vado no próximo segmento. O mapa de nó-i, então, deve 
ser atualizado para apontar para a nova cópia. Contudo, é 
possível fazer a administração, e os resultados de desempe¬ 
nho mostram que toda essa complexidade é vantajosa. As 
medidas dadas nos papers citados anteriormente mostram 
que o desempenho do LFS superam o do UNIX em uma or¬ 
dem de magnitude em pequenas gravações, enquanto têm 
um desempenho que é tão bom ou melhor que o do UNIX 
para leituras e para gravações grandes. 

5.4 SEGURANÇA 

Os sistemas de arquivos com freqüência contêm infor¬ 
mações extremamente valiosas para seus usuários. Prote¬ 
ger essas informações contra o uso não-autorizado é, por¬ 
tanto, uma questão importante para todos os sistemas de 
arquivos. Nas seções a seguir veremos diversas questões re¬ 
lacionadas com segurança e com proteção. Essas questões 
aplicam-se igualmente à maioria dos sistemas de compar¬ 
tilhamento de tempo, bem como a redes de computadores 
pessoais conectadas a servidores compartilhados via redes 
locais. 

5.4.1 Ambiente de Segurança 

Os termos “segurança” e “proteção” são frequentemen¬ 
te utilizados de maneira intercambiável. Contudo, com fre¬ 
qüência, é útil fazer uma distinção entre os problemas ge¬ 
rais envolvidos em assegurar-se de que os arquivos não se¬ 
jam lidos nem modificados por pessoas não-autorizadas, o 
que inclui questões políticas, legais, administrativas e téc¬ 
nicas, de um lado, e os mecanismos específicos do sistema 
operacional utilizados para oferecer segurança, do outro. 
Para evitar confusão, utilizaremos o termo segurança para 
referirmo-nos ao problema total, e o termo mecanismos 
de proteção para referirmo-nos aos mecanismos específi¬ 
cos do sistema operacional utilizados para salvaguardar as 
informações no computador. A linha divisória entre eles, 
entretanto, não é bem-definida. Primeiro veremos segu¬ 
rança; mais adiante no capítulo veremos proteção. 

A segurança tem muitos aspectos. Dois dos mais impor¬ 
tantes são a perda de dados e os intrusos. Algumas causas 
comuns de perda de dados são: 


1. Ações divinas: incêndios, inundações, terremotos, 
guerras, revoltas ou ratos que roem fitas ou dis¬ 
quetes. 

2. Erros de hardware ou de software: malfunciona- 
mento da CPU, discos ou fitas ilegíveis, erros de 
telecomunicação, bugs de programa. 

3. Erros humanos: entrada incorreta de dados, mon¬ 
tagem incorreta de fita ou de disco, execução erra¬ 
da de programa, perda de disco ou de fita ou al¬ 
gum outro engano. 

A maioria desses pode ser tratada mantendo-se backups 
adequados, preferivelmente longe dos dados originais. 

Um problema mais interessante é o que fazer com in¬ 
trusos. Esses se classificam em dois tipos. Intrusos passivos 
somente querem ler arquivos que eles não são autorizados 
a ler. Intrusos ativos são mais maliciosos; eles querem fa¬ 
zer alterações não-autorizadas nos dados. Ao projetar um 
sistema para ser seguro contra intrusos, é importante ter 
em mente o tipo de intruso contra o qual se está tentando 
criar proteção. Algumas categorias comuns são: 

1. Bisbilhotice casual por usuários não-técnicos. 
Muitas pessoas têm terminais para sistemas de 
compartilhamento de tempo ou para computado¬ 
res pessoais em rede em suas mesas, e a natureza 
humana sendo a que é, algum deles lerão correio 
eletrônico e outros arquivos de outras pessoas se 
nenhuma barreira for colocada no caminho. A 
maioria dos sistemas UNIX, por exemplo, tem como 
padrão que todos os arquivos são publicamente 
legíveis. 

2. Espionagem por pessoas de dentro. Alunos, progra¬ 
madores de sistema, operadores e outro pessoal téc¬ 
nico, com freqüência, consideram ser um desafio 
pessoal quebrar a segurança do sistema local de 
computador. Eles seguidamente são bastante ha¬ 
bilidosos e estão disposto a dedicar uma quantida¬ 
de significativa de tempo nesse esforço. 

3. Tentativa determinada de fazer dinheiro. Alguns 
programadores de instituições bancárias tentaram 
quebrar um sistema de depósitos para roubar um 
banco. Os esquemas variavam desde a alteração 
do software para truncar em vez de arredondar a 
taxa de juros, mantendo as frações de um centavo 
para eles próprios, até o furto de contas não-utili- 
zadas há anos, e chantagem (“Paguem-me ou 
destruirei todos os registros do banco”.) 

4. Espionagem comercial ou militar. Espionagem re- 
fere-se a uma tentativa mais séria e bem-financia- 
da por um concorrente ou por um país estrangeiro 
para roubar programas, segredos de negócio, pa¬ 
tentes, tecnologia, projetos de circuitos, planos de 
marketing, etc. Freqüentemente essa tentativa en¬ 
volverá grampeamento ou mesmo montar ante¬ 
nas dirigidas para o computador a fim de captar 
sua radiação electromagnética. 
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Deve estar claro que tentar impedir um governo estrangei¬ 
ro hostil de roubar segredos militares é uma questão bem 
diferente de tentar impedir alunos de inserir uma “mensa¬ 
gem do dia engraçada” no sistema. A quantidade de esfor¬ 
ço aplicada em segurança e proteção depende muito do 
inimigo considerado. 

Outro aspecto do problema da segurança é a privaci¬ 
dade: proteger indivíduos do abuso das informações sobre 
eles. Isso rapidamente leva a muitas questões morais e 
jurídicas. O governo deve compilar dossiês sobre todo mun¬ 
do para capturar fraudadores de.r, onde.v é “previdência 
social” ou “imposto de renda”, dependendo da sua políti¬ 
ca? A polícia deve ser capaz de pesquisar qualquer coisa 
sobre qualquer pessoa para combater o crime organizado? 
Os empregadores e as companhias de seguro têm direitos? 
O que acontece quando esses direitos entram em conflito 
com os direitos do indivíduo? Todas essas questões são ex¬ 
tremamente importantes, mas estão além do âmbito deste 
livro. 

5.4.2 Falhas Famosas de Segurança 

Assim como a indústria dos transportes tem seu Titanic 
e o seu Hindenburg , os peritos de segurança de computa¬ 
dor têm algumas coisas das quais jamais se esquecerão. 
Nesta seção, veremos alguns problemas interessantes de se¬ 
gurança que ocorreram em três sistemas operacionais di¬ 
ferentes: UNIX, TENEX e OS/360. 

0 utilitário Ipr do UNIX, que imprime um arquivo na 
impressora de linha, tem uma opção para remover o ar¬ 
quivo depois que ele foi impresso. Em versões primitivas do 
UNIX, era possível qualquer pessoa utilizar Ipr para impri¬ 
mir e, então, fazer o sistema remover o arquivo de senhas. 

Outra maneira de invadir o UNIX era vincular um ar¬ 
quivo chamado core no diretório de trabalho ao arquivo de 
senha. O intruso, então, forçava um dump de núcleo de 
um programa SETUID, que o sistema gravava no arquivo 


core , isto é, sobre o arquivo de senhas. Dessa maneira, um 
usuário poderia substituir o arquivo de senhas por outro 
contendo algumas strings da sua própria escolha (p. ex., 
argumentos de comando). 

Ainda, outra falha sutil no UNIX envolvia o comando 

mkdir foo 

mkdir, que era um programa SETUID possuído pela raiz, 
primeiro criava o nó-i para o diretório foo com a chamada 
de sistema MKNOD e, então, alterava o proprietário de foo 
de seu uid efetivo (i. e., raiz) para seu uid real (o uid do 
usuário). Quando o sistema era lento, às vezes, era possível 
ao usuário rapidamente remover o nó-i do diretório e fazer 
um link para o arquivo de senha sob o nome de foo depois 
do MKNOD, mas antes do CHOWN. Quando mkdir fazia o 
CHOWN, o usuário tornava-se o proprietário do arquivo de 
senha. Colocando os comandos necessários em um script 
de sbell, isso podia ser feito repetidamente até o truque fun¬ 
cionar. 

O sistema operacional TENEX costumava ser muito po¬ 
pular nos computadores DEC-10. Ele não é mais utilizado, 
mas sobreviverá eternamente nos anais de segurança de 
computador devido ao seguinte erro de projeto. O TENEX 
suportava paginação. Para permitir que os usuários moni¬ 
torassem o comportamento de seus programas, era possí¬ 
vel instruir o sistema a chamar uma função de usuário a 
cada falha de página. 

O TENEX também utilizava senhas para proteger os ar¬ 
quivos. Para acessar um arquivo, um programa precisava 
apresentar a senha adequada. O sistema operacional veri¬ 
ficava as senhas um caractere por vez, parando logo que 
via que a senha estava errada. Para penetrar no TENEX, um 
intruso cuidadosamente posicionaria uma senha como 
mostrado na Figura 5-20(a), com o primeiro caractere no 
fim de uma página e o restante no início da próxima página. 

O próximo passo era certificar-se de que a segunda pá¬ 
gina não estivesse na memória, por exemplo, referencian- 
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Figura 5-20 0 problema de senha do TENEX. 
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do tantas outras páginas que a segunda página seria segu¬ 
ramente expulsa para dar lugar a elas. Agora o programa 
tentava abrir o arquivo da vítima, utilizando a senha cui¬ 
dadosamente alinhada. Se o primeiro caractere da senha 
real fosse qualquer coisa exceto d, o sistema pararia para 
verificar o primeiro caractere e retornaria um informe de 
ILLEGAL PASSWORD. Se, entretanto, a senha real come¬ 
çasse comzl, o sistema continuava a leitura e obtinha uma 
falha de página, sobre a qual o intruso era informado. 

Se a senha não começasse com d, o intruso alterava a 
senha para a da Figura 5-20(b) e repetia o processo inteiro 
para ver se começava com B. No máximo, 128 tentativas 
seriam necessárias para percorrer todo o conjunto de ca¬ 
racteres ASCII e assim determinar o primeiro caractere. 

Supondo que o primeiro caractere fosse umF. O arran¬ 
jo de memória da Figura 5-20(c) permitia que o intruso 
testasse cadeias de caracteres na forma FA,FBe assim por 
diante. Utilizando essa abordagem que levava no máximo 
128 n tentativas para adivinhar uma senha de n caracteres 
ASCII, em vez de 128". 

Nossa última falha diz respeito ao os/ 360 . A descrição 
que se segue é ligeiramente simplificada, mas conserva a 
essência da falha. Esse sistema podia iniciar uma leitura 
de fita e, então, continuar a computação enquanto a uni¬ 
dade de fita estava transferindo dados para 0 espaço do usu¬ 
ário. O truque aqui é cuidadosamente iniciar uma leitura 
de fita e, então, fazer uma chamada de sistema que solici¬ 
tava uma estrutura de dados do usuário, por exemplo, um 
arquivo para ler e sua senha. 

0 sistema operacional primeiro verificava se a senha 
era de fato a correta para 0 arquivo dado. Então, ele volta¬ 
va e lia 0 nome do arquivo novamente para 0 acesso real 
(ele podia salvar 0 nome internamente, mas não fazia isso). 
Infelizmente, logo antes de 0 sistema buscar 0 nome do 
arquivo pela segunda vez, 0 nome do arquivo era sobres¬ 
crito pela unidade de fita. O sistema, então, lia 0 novo ar¬ 
quivo, para 0 qual nenhuma senha fora apresentada. Para 
conseguir a sincronização correta era necessária alguma 
prática, mas isso não era tão difícil. Ale'm disso, se há uma 
coisa em que computadores são bons, é executar a mesma 
operação repetidamente ad nauseam. 

Além desses exemplos muitos outros problemas de se¬ 
gurança e de ataques surgiram com os anos. Um que apa¬ 
receu em muitos contextos é 0 cavalo de Tróia, no qual 
um programa aparentemente inocente que é amplamente 
distribuído também executa alguma função indesejável e 
inesperada, como roubar dados e enviá-los por correio ele¬ 
trônico para algum site distante onde podem ser reunidos 
mais tarde. 

Outro problema de segurança nesses tempos de insegu¬ 
rança de trabalho é 0 da bomba lógica. Esse dispositivo é 
um pequeno código escrito por um dos programadores de 
uma empresa (no momento sendo empregado) e secreta¬ 
mente inserido no sistema operacional de produção. Con¬ 
tanto que 0 programador alimente-o com sua senha diari¬ 
amente, ele não faz nada. Entretanto, se 0 programador 
repentinamente é despedido e fisicamente removido das pre¬ 


missas sem aviso, no dia seguinte em que a bomba lógica 
não recebe sua senha, ela dispara. 

O disparo talvez envolva limpar 0 disco, apagar arqui¬ 
vos aleatoriamente, fazer cuidadosas alterações difíceis de 
detectar em programas-chave ou criptografar arquivos es¬ 
senciais. Neste último caso, a empresa precisará fazer uma 
difícil escolha entre chamar a polícia (que pode ou não 
resultar em uma condenação muitos meses mais tarde) ou 
ceder a essa chantagem e recontratar 0 ex-programador 
como um “consultor” por uma soma astronômica para 
corrigir 0 problema (e esperar que ele não plante novas 
bombas lógicas enquanto faz isso). 

Provavelmente a maior violação da segurança de com¬ 
putadores de todos os tempos começou na noite de 2 de 
novembro de 1988 quando um aluno graduado em Corne- 
11, Robert Tappan Morris, lançou um programa-verme na 
Internet que acabou derrubando milhares de máquinas por 
todo 0 mundo. 

O verme consistia em dois programas, 0 comando de 
partida ( bootstrap ) e 0 verme em si. O programa de parti¬ 
da era constituído por 99 linhas em C de chamadas ll.c. 
Ele era compilado e executado no sistema sob ataque. Uma 
vez em execução, ele se conectava à máquina de que veio, 
carregava 0 verme principal e executava-o. Após passar por 
algumas etapas complicadas para ocultar sua existência, 0 
verme, então, pesquisava as tabelas de roteamento do seu 
novo host para ver com que máquinas esse host estava co¬ 
nectado e tentava espalhar 0 comando de partida para es¬ 
sas máquinas. 

Uma vez estabelecido em uma máquina, 0 verme ten¬ 
tava quebrar as senhas de usuário. Morris não precisou 
pesquisar muito para descobrir como fazer isso. Tudo que 
ele precisou fazer foi pedir a seu pai, um perito de seguran¬ 
ça na Agência Nacional de Segurança, 0 supersecreto ór¬ 
gão do governo norte-americano encarregado de quebrar 
códigos de segurança, uma reimpressão de um paper clás¬ 
sico sobre 0 assunto que Sr. Morris e Ken Thompson ti¬ 
nham escrito uma década antes no Bell Labs (Morris e 
Thompson, 1979). Cada senha quebrada permitia que 0 
verme se conectasse a quaisquer máquinas em que 0 pro¬ 
prietário da senha tivesse contas. 

Morris foi capturado quando um de seus amigos falou 
com 0 repórter de informática do New York Times. John 
Markoff, e tentou convencer Markoff de que 0 incidente foi 
um acidente, 0 verme era inofensivo e 0 autor lamentava 
muito tudo aquilo. No dia seguinte, a história ganhou as 
manchetes dos jornais, tirando a atenção até mesmo da 
eleição presidencial três dias depois. Morris foi julgado e 
condenado na corte suprema. Ele foi sentenciado a uma 
multa de 10 mil dólares, três anos de condicional e 400 
horas de serviços comunitários. Seus custos advocatícios 
provavelmente excederam 150 mil dólares. 

Essa sentença gerou muita controvérsia. Muitos na co¬ 
munidade da informática acreditavam que ele era um bri¬ 
lhante aluno da graduação cuja inofensiva brincadeira ti¬ 
nha saído do seu controle. Nada no verme de Morris suge¬ 
ria que ele estava tentando roubar ou danificar qualquer 
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coisa. Outros o consideravam um criminoso sério que de¬ 
veria ir para a cadeia. 

Um efeito permanente desse incidente foi o estabeleci¬ 
mento do CERT (Computer Emergency Response Team 

— equipe de resposta à emergências relacionadas a com¬ 
putadores), que oferece uma central de informações sobre 
tentativas de invasão, e um grupo de peritos para analisar 
problemas de segurança e desenvolver soluções para tais 
problemas. Embora essa ação certamente tenha dado um 
passo a frente, ela também deu um passo para trás. 0 CERT 
reúne defeitos de sistemas que podem ser atacados e infor¬ 
mações sobre como corrigi-los. Em função da necessidade, 
ele faz circular amplamente essas informações para mi¬ 
lhares de administradores de sistema na Internet, o que 
significa que também os mal-intencionados podem ser 
capazes de obtê-las e explorar as brechas nas horas (ou 
mesmo dias) antes de o acesso ser fechado. 

5.4.3 Ataques de Segurança Genéricos 

As falhas descritas acima foram corrigidas, mas 0 siste¬ 
ma operacional médio ainda tem mais lacunas do que uma 
peneira. A maneira normal de testar a segurança de um 
sistema é empregar um grupo de peritos, conhecidos como 
equipes de invasão, para ver se eles podem quebrá-la. 
Hebbard e colaboradores (1980) tentaram a mesma coisa 
com alunos de graduação. No curso dos anos, essas equi¬ 
pes de invasão descobriram diversas áreas em que os siste¬ 
mas podem ser vulneráveis. A seguir, listamos alguns ata¬ 
ques mais comuns que freqüentemente são bem-sucedi¬ 
dos. Ao projetar um sistema, esteja seguro de que pode com¬ 
bater ataques como estes. 

1. Solicite páginas de memória, espaço em disco ou 
fitas e simplesmente os leia. Muitos sistemas não 
os apagam antes de alocá-los e eles podem estar 
cheios de informações interessantes, gravadas pelo 
proprietário anterior. 

2. Tente chamadas de sistema ilegais ou chamadas 
de sistema legais com parâmetros ilegais ou cha¬ 
madas de sistema legais comuns com parâmetros 
legais, mas improváveis. Muitos sistemas facilmen¬ 
te podem ser confundidos. 

3. Inicie efetuando logon e, então, pressione DEL, RU- 
BOUT ou BREAK no meio da seqüência de login. 
Em alguns sistemas, 0 programa que verifica a se¬ 
nha será eliminado, e 0 login considerado bem- 
sucedido. 

4. Tente modificar as estruturas complexas mantidas 
pelo sistema operacional no espaço do usuário (se 
houver alguma). Em alguns sistemas (especial¬ 
mente em mainframe s), para abrir um arquivo, 
0 programa constrói uma grande estrutura de da¬ 
dos que contém 0 nome de arquivo e de muitos 
outros parâmetros, e passa-os para 0 sistema. En¬ 
quanto 0 arquivo é lido e gravado, 0 sistema, às 


vezes, atualiza a própria estrutura. A alteração des¬ 
ses campos pode devastar a segurança. 

5. Experimente ludibriar 0 usuário, escrevendo um 
programa que escreva “login": na tela e segue adi¬ 
ante. Muitos usuários irão até 0 terminal e dili¬ 
gentemente informarão seu nome de login e sua 
senha, que 0 programa cuidadosamente grava para 
seu maligno mestre. 

6 . Procure manuais que dizem “não façaáT. Tente 0 
máximo de variações possíveis de.r. 

7. Convença um programador de sistema a alterar 0 
sistema para burlar certas verificações de segurança 
vitais para qualquer usuário com seu nome de lo¬ 
gin. Esse ataque é conhecido como porta de in¬ 
terrupção (ou porta dos fundos). 

8 . Se tudo isso falhar, 0 invasor pode encontrar a se¬ 
cretária do diretor do centro de computadores e 
oferecer-lhe um grande suborno. A secretária 
provavelmente tem acesso fácil a todo tipo de in¬ 
formações maravilhosas e, em geral, é mal paga. 
Não subestime problemas causados por funcioná¬ 
rios. 

Esses e outros ataques são discutidos por Linde (1975). 

Vírus 

Uma categoria especial de ataque é 0 vírus de compu¬ 
tador, que se tornou um problema importante para muitos 
usuários de computador. Um vírus é um fragmento de pro¬ 
grama que é unido a um programa legítimo com a inten¬ 
ção de infectar outros programas. Difere de um verme so¬ 
mente no ponto em que um vírus vale-se de um programa 
existente, enquanto um verme é um programa completo 
em si. Vírus e vermes tentam espalhar-se e ambos fazem 
estragos graves. 

Um vírus típico trabalha da seguinte maneira. A pessoa 
que escreve 0 vírus primeiro produz um novo programa 
útil, freqüentemente um jogo para MS-DOS. Esse programa 
contém 0 código do vírus oculto dentro dele. O jogo é, en¬ 
tão, carregado para um BBS público ou oferecido de graça 
ou por um preço modesto em disquete. 0 programa, então, 
é divulgado, e as pessoas começam a carregá-lo e a utilizá- 
lo. Construir um vírus não é tão fácil, portanto, as pessoas 
que fazem isso invariavelmente são bastante inteligentes, 
e a qualidade do jogo ou outro programa freqüentemente 
é excelente. 

Quando 0 programa é iniciado, ele imediatamente co¬ 
meça a examinar todos os programas binários no disco rí¬ 
gido para ver se eles já estão infectados. Quando um pro¬ 
grama não-infectado é localizado, ele é infectado anexan¬ 
do-se código do vírus ao final do arquivo e substituindo a 
primeira instrução por um salto para 0 vírus. Quando 0 
código do vírus termina de executar, ele executa a instru¬ 
ção que anteriormente era a primeira e, então, salta para a 
segunda instrução. Dessa maneira, toda vez que um pro- 
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grama infectado executa, ele tenta infectar mais progra¬ 
mas. 

Além de simplesmente infectar outros programas, um 
vírus pode fazer outras coisas, como apagar, modificar ou 
criptografar arquivos. Um vírus chega ao desplante de exi¬ 
bir uma carta de extorsão na tela, dizendo para o usuário 
enviar 500 dólares em dinheiro para uma caixa de correio 
no Panamá ou que se conforme com a perda permanente 
de seus dados e com o estrago do hardware. 

Um vírus também pode infectar o setor de inicialização 
do disco rígido, tornando impossível inicializar o compu¬ 
tador. Um vírus assim pode pedir uma senha, que o escri¬ 
tor do vírus pode fornecer em troca de algumas notas pe¬ 
quenas não-marcadas. 

Os problemas de vírus são mais fáceis de prevenir do 
que remediar. O curso seguro é comprar somente software 
na caixa original, em lojas de confiança. Carregar softwa¬ 
re livre de BBSs ou obter cópias pirateadas em disquetes é 
chamar problemas. Existem pacotes comerciais de antiví¬ 
rus, mas alguns desses funcionam pesquisando apenas ví¬ 
rus conhecidos específicos. 

Uma abordagem mais geral é primeiro reformatar o 
disco rígido completamente, incluindo o setor de iniciali¬ 
zação. Em seguida, instalar todo o software confiável e cal¬ 
cular uma soma de verificação para cada arquivo. O algo¬ 
ritmo não importa, contanto que tenha bits suficientes (pelo 
menos 32). Armazene a lista de pares (arquivo, soma de 
verificação) em um lugar seguro, seja offline em um dis¬ 
quete sej a online, mas criptografado. Iniciando nesse pon¬ 
to, sempre que o sistema inicializar, todas as somas de ve¬ 
rificação devem ser recomputadas e deverão ser compara¬ 
das com a lista segura de somas de verificação originais. 
Qualquer arquivo cuja soma de verificação atual difere da 
original é imediatamente duvidoso. Embora essa aborda¬ 
gem não impeça a infecção, pelo menos permite detectar 
cedo sua presença. 

A infecção pode ser tornada mais difícil se o diretório 
onde programas binários residem é tornado não-gravável 
para usuários comuns. Essa técnica torna difícil o vírus 
modificar outros binários. Embora possa ser utilizado no 
UNIX, não é aplicável ao MS-DOS porque os diretórios do 
último não podem ser tornados não-graváveis de modo al¬ 
gum. 

5-4.4 Princípios de Projeto para 
Segurança 

Os vírus ocorrem principalmente em sistemas desktop. 
Em sistemas maiores, outros problemas ocorrem e outros 
métodos são necessários para lidar com eles. Saltzer e Schro- 
eder (1975) identificaram vários princípios gerais que po¬ 
dem ser utilizados como guia para projetar sistemas segu¬ 
ros. Um breve resumo de suas idéias (baseadas em experi¬ 
ências com o MULTICS) é fornecido a seguir. 

Primeiro, o projeto de sistema deve ser público. Assu¬ 
mir que o intruso não saberá como o sistema funciona ser¬ 
ve somente para iludir os projetistas. 


Segundo, o padrão deve ser nenhum acesso. Os erros 
em que acesso legítimo é recusado serão informados mui¬ 
to mais rapidamente do que erros em que acesso não-au- 
torizado foi permitido. 

Terceiro, verificar a autoridade atual. O sistema não deve 
verificar permissão, determinar que acesso é permitido e, 
então, esconder longe essas informações para utilização 
subseqüente. Muitos sistemas verificam permissão quando 
um arquivo é aberto e não depois. Isso significa que um 
usuário que abre um arquivo e mantém-no aberto durante 
semanas, continuará a ter acesso, mesmo se o proprietário 
tiver alterado a proteção do arquivo há muito tempo. 

Quarto, dê a cada processo o menor privilégio possível. 
Se um editor tem somente a autoridade para acessar o ar¬ 
quivo a ser editado (especificado quando o editor é invoca¬ 
do), editores com cavalos de Tróia não serão capazes de 
fazer muito estrago. Esse princípio implica um esquema 
de proteção refinado. Discutiremos tais esquemas mais adi¬ 
ante neste capítulo. 

Quinto, o mecanismo de proteção deve ser simples, 
uniforme e construído nas camadas mais baixas do siste¬ 
ma. Tentar inserir segurança em um sistema existente in¬ 
seguro é quase impossível. A segurança, como a precisão, 
não é um recurso suplementar. 

Sexto, o esquema escolhido deve ser psicologicamente 
aceitável. Se usuários acham que proteger seus arquivos 
dá muito trabalho, eles simplesmente não farão isso. Con¬ 
tudo, eles se queixarão muito se algo der errado. As respos¬ 
tas na forma “o erro foi seu” geralmente não serão bem- 
recebidas. 

5-4.5 Autenticação do Usuário 

Muitos esquemas de proteção são baseados na suposi¬ 
ção de que o sistema sabe a identidade de cada usuário. O 
problema de identificar usuários quando eles se conectam 
é chamado autenticação de usuário. A maioria dos mé¬ 
todos de autenticação é baseada em identificar algo que o 
usuário sabe, algo que o usuário tem ou algo que o usuá¬ 
rio é. 

Senhas 

A forma mais amplamente utilizada de autenticação é 
solicitar ao usuário que digite uma senha. A proteção por 
senhas é fácil de entender e fácil de implementar. No UNIX 
funciona da seguinte maneira. O programa de login soli¬ 
cita que o usuário digite seu nome e sua senha. A senha é 
imediatamente criptografada. O programa de login, en¬ 
tão, lê o arquivo de senhas, que é uma série de linhas AS¬ 
CII, uma por usuário, até que localiza a linha que contém 
nome de login do usuário. Se a senha (criptografada) con¬ 
tida nessa linha coincidir com a senha criptografada que 
acabou de ser computada, o login é permitido, caso con¬ 
trário é recusado. 

A autenticação por senha é fácil de derrotar. Lemos com 
freqüência sobre grupos de alunos de faculdade, ou mes- 
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mo do segundo grau, que com a ajuda de seus confiáveis 
computadores domésticos simplesmente invadem algum 
sistema secreto de alto nível de uma grande corporação ou 
de um órgão do governo. Praticamente todo o tempo gasto 
em uma invasão consiste em adivinhar uma combinação 
de nome de usuário e de senha. 

Embora estudos mais recentes tenham sido feitos (p. ex., 
Klein, 1990), 0 trabalho clássico sobre segurança por se¬ 
nhas continua sendo 0 feito por Morris e Thompson (1979) 
para sistemas UNIX. Eles compilaram uma lista de senhas 
possíveis: nomes e sobrenomes, nomes de rua, nomes de 
cidade, palavras de um dicionário de tamanho médio (tam¬ 
bém palavras soletradas de trás para a frente), números de 
placas de licença e cadeias curtas de caracteres aleatórios. 

Eles, então, criptografaram cada um desses, utilizando 
0 algoritmo conhecido de criptografia de senha e verifica¬ 
ram se qualquer das entradas de senhas criptografadas co¬ 
incidia com sua lista. Mais de 86% de todas as senhas caí¬ 
ram em sua lista. 

Se todas as senhas consistissem em 7 caracteres esco¬ 
lhidos aleatoriamente dos 95 caracteres ASCII imprimíveis, 

0 espaço de pesquisa iria tornar-se 95 7 , que é aproximada¬ 
mente 7x 10 1 - 5 . À velocidade de 1.000 criptografias por se¬ 
gundo, levaria 2.000 anos para construir a lista contra a 
qual se poderia verificar um arquivo de senhas. Além disso, 
a lista preencheria 20 milhões de fitas magnéticas. Mesmo 
impondo que as senhas contenham pelo menos um carac¬ 
tere em letras minúsculas, um caractere em letras maiús- 
culas e um caractere especial e tenham pelo menos sete ou 
oito caracteres de comprimento seria uma melhora impor¬ 
tante em relação às senhas irrestritas escolhidas pelos usu¬ 
ários. 

Mesmo se for considerado politicamente impossível so¬ 
licitar que os usuários selecionem senhas razoáveis, Mor¬ 
ris e Thompson descreveram uma técnica que deixa 0 pró¬ 
prio ataque (criptografar um número grande de senhas de 
antemão) quase inútil. Sua idéia é associar um número 
aleatório de n bits a cada senha. O número aleatório é al¬ 
terado sempre que a senha é alterada. O número aleatório 
é armazenado no arquivo de senha na forma não-cripto- 
grafada, de modo que todo 0 mundo possa lê-lo. Em vez de 
simplesmente armazenar a senha criptografada no arqui¬ 
vo de senha, a senha e 0 número aleatório são primeiro 
concatenados e, então, criptografados juntos. Esse resulta¬ 
do criptografado é armazenado no arquivo de senhas. 

Agora considere as implicações para um intruso que 
queira acumular uma lista de senhas possíveis, criptogra- 
fá-las e salvar 0 resultado em um arquivo classificado,/, de 
modo que qualquer senha criptografada possa ser pesqui¬ 
sada facilmente. Se um intruso suspeita que Marilyn tal¬ 
vez tenha uma senha, não é mais suficiente apenas cripto¬ 
grafar Marilyn e colocar 0 resultado em /. Ele terá de crip¬ 
tografar 2 n strings, como MarilynOOOO, MarilynOOOl , 
Marilyn0002, etc., e inserir todas elas em/ Essa técnica 
aumenta 0 tamanho de/por 2". 0 UNIX utiliza esse método 
com n - 12. É conhecido como salgar 0 arquivo de se¬ 
nhas. Algumas versões do UNIX tornam ilegível 0 próprio 


arquivo de senhas, mas oferecem um programa para pes¬ 
quisar entradas no momento da solicitação, adicionando 
retardo suficiente para reduzir significativamente a veloci¬ 
dade do trabalho de qualquer intruso. 

Embora esse método ofereça proteção contra intrusos 
que tentarem previamente computar uma lista grande de 
senhas criptografados, ele faz pouco para proteger um usu¬ 
ário David cuja senha é também David. Uma maneira de 
encorajar as pessoas a selecionar melhores senhas é fazer 
0 computador oferecer esse aconselhamento. Alguns com¬ 
putadores têm um programa que gera palavras sem senti¬ 
do aleatórias fáceis de pronunciar, como fotalmente, lixe- 
ria ou bipedade que você pode utilizar como senhas (pre¬ 
ferivelmente com alguma letra maiúscula e caracteres es¬ 
peciais no meio). 

Outros computadores exigem que os usuários alterem 
suas senhas regularmente, limitando 0 estrago feito se uma 
senha vazar. A forma mais extrema dessa abordagem é a 
senha de uma vez. Quando senhas de uma vez são utili¬ 
zadas, 0 usuário recebe um livro que contém uma lista de 
senhas. Cada logín utiliza a próxima senha na lista. Se um 
intruso vier a descobrir uma senha, ele não fará muito com 
ela, uma vez que da próxima vez uma senha diferente de¬ 
verá ser utilizada. Recomenda-se que 0 usuário tente evi¬ 
tar perder 0 livro de senhas. 

Também é óbvio que, quando uma senha está sendo 
digitada, 0 computador não deve exibir os caracteres digi¬ 
tados, para ocultá-los de olhos bisbilhoteiros próximos do 
terminal. O que é menos óbvio é que as senhas nunca de¬ 
vem ser armazenadas no computador na forma não-crip- 
tografada. Além disso, nem mesmo 0 CPD deveria guardar 
cópias não-criptografadas. Armazenar senhas não-cripto- 
grafadas é procurar problemas. 

Uma variação na idéia de senha é oferecer a cada novo 
usuário uma longa lista de perguntas e de respostas que, 
então, são armazenadas no computador na forma cripto¬ 
grafada. As perguntas devem ser escolhidas de modo que 0 
usuário não necessite escrevê-las. Perguntas típicas são: 

1. Quem é a irmã de Tânia? 

2. Em que rua ficava sua escola primária? 

3. O professor Gustavo dava aulas de quê? 

No momento do login, 0 computador solicita uma delas 
aleatoriamente e verifica a resposta. 

Outra variação é a resposta a desafio. Quando isso é 
utilizado, 0 usuário seleciona um algoritmo quando se ins¬ 
creve como um usuário, x 2 , por exemplo. Quando 0 usuá¬ 
rio estiver conectado, 0 computador digita um argumento, 
digamos 7, caso em que 0 usuário digita 49. O algoritmo 
pode ser diferente de manhã e à tarde, em dias diferentes 
da semana, em terminais diferentes e assim por diante. 

Identificação Física 

Uma abordagem completamente diferente para autori¬ 
zação é verificar se 0 usuário tem algum item, normal¬ 
mente um cartão de plástico com uma tarja magnética. 0 
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cartão é inserido no terminal, que, então, verifica de quem 
é esse cartão. Esse método pode ser combinado com uma 
senha; então, um usuário somente pode conectar-se se ele 
(1) tiver o cartão e (2) souber a senha. Os caixas automá¬ 
ticos de bancos geralmente funcionam dessa maneira. 

Outra abordagem é medir as características físicas que 
são difíceis de falsificar. Por exemplo, uma impressão digi¬ 
tal ou um leitor de voz no terminal poderia verificar a iden¬ 
tidade do usuário. (A pesquisa será mais rápida se o usuá¬ 
rio informar ao computador quem ele é, em vez de fazer o 
computador comparar a impressão digital dada em todo o 
banco de dados.) Reconhecimento visual direto ainda não 
é praticável, mas um dia pode vir a ser. 

Outra técnica é a análise da assinatura. O usuário assi¬ 
na seu nome com uma caneta especial conectada ao ter¬ 
minal e o computador compara-o on-line a uma amostra 
conhecida e armazenada. Melhor ainda é comparar não a 
assinatura, mas sim os movimentos da caneta enquanto 
ela está sendo escrita. Um bom falsificador pode ser capaz 
de copiar a assinatura, mas não terá uma pista da ordem 
exata em que os movimentos foram feitos. 

A análise do comprimento dos dedos é surpreendente¬ 
mente prática. Quando isso é utilizado, cada terminal tem 
um dispositivo como o da Figura 5-21. O usuário insere a 
sua mão nele, e o comprimento de todos seus dedos é me¬ 
dido e verificado contra o banco de dados. 

Poderíamos prosseguir com mais exemplos, porém dois 
ajudarão a tomar mais claro um ponto importante. Os gatos 
e outros animais marcam seu território urinando no seu 
perímetro. Aparentemente gatos podem identificar-se des¬ 
sa maneira. Suponha que alguém apareça com um dispo¬ 
sitivo minúsculo capaz de fazer uma análise da urina ins¬ 



tantânea, oferecendo assim uma identificação à prova de 
falhas. Cada terminal poderia ser equipado com um desses 
dispositivos, junto com um discreto aviso dizendo: “Para 
login , por favor deposite a amostra aqui”. Talvez esse seja 
um sistema absolutamente inquebrável, mas provavelmente 
teria um sério problema de aceitação por parte do usuário. 

0 mesmo poderia ser dito de um sistema consistindo 
em um coletor e em um pequeno espectrógrafo. 0 usuário 
seria solicitado a pressionar seu polegar contra o coletor, 
extraindo assim uma gota de sangue para análise espec- 
trográfica. 0 ponto é que qualquer esquema de autentica¬ 
ção deve ser psicologicamente aceitável para a comunida¬ 
de de usuários. As medidas do comprimento do dedo pro¬ 
vavelmente não causarão qualquer problema, mas mesmo 
algo tão pouco indiscreto ou inconveniente como armaze¬ 
nar impressões digitais on-line pode ser inaceitável para 
muitas pessoas. 

Con trame didas 

As instalações de computador que são realmente sérias 
quanto à segurança, algo que, com freqüência, acontece 
no dia seguinte depois que um invasor quebrou a seguran¬ 
ça e fez um estrago importante, frequentemente adotam 
passos para tomar uma entrada não-autorizada muito mais 
difícil. Por exemplo, cada usuário poderia ter permissão 
para conectar-se somente a partir de um terminal específi¬ 
co e apenas durante certos dias da semana e em certas ho¬ 
ras do dia. 

Linhas de telefone discadas poderiam funcionar da se¬ 
guinte maneira. Qualquer pessoa pode discar e conectar- 
se, mas após um login bem-sucedido, o sistema imediata- 



Figura 5-21 Um dispositivo para medir comprimento dos dedos. 
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mente derruba a conexão e chama de volta o usuário em 
um número previamente definido. Essa medida significa 
que um intruso não pode quebrar a segurança a partir de 
qualquer linha de telefone, mas sim apenas a partir do te¬ 
lefone (de casa) do usuário. Em qualquer caso, com ou 
sem retorno de chamada, o sistema deve levar pelo menos 
10 segundos para verificar qualquer senha digitada em uma 
linha discada e deve aumentar esse tempo após várias ten¬ 
tativas de login consecutivas malsucedidas, para reduzir a 
velocidade das tentativas do intruso. Após três tentativas 
falhas de login , a linha deve ser desconectada por 10 mi¬ 
nutos, e o pessoal de segurança notificado. 

Todos os logins devem ser registrados. Quando um usu¬ 
ário efetua login, o sistema deve informar o momento e o 
terminal do login anterior, assim ele pode detectar uma 
possível invasão. 

O próximo passo é estabelecer armadilhas na forma de 
iscas para capturar intrusos. Um esquema simples é ter um 
nome especial de login com uma senha fácil (p. ex., nome 
de login-, guest, senha: guesf). Sempre que qualquer pes¬ 
soa conectar-se, utilizando esse nome, os especialistas de 
segurança de sistema imediatamente são notificados. Ou¬ 
tras armadilhas podem ser bugs “fáceis de achar" no siste¬ 
ma operacional e coisas semelhantes, projetados com o 
propósito de capturar intrusos no ato. Stoll (1989) escre¬ 
veu um relato divertido das armadilhas que ele montou 
para rastrear um espião que invadiu um computador de 
uma universidade, procurando segredos militares. 

5.5 MECANISMOS DE PROTEÇÃO 

Nas seções anteriores, vimos muitos problemas poten¬ 
ciais, algum deles técnicos e alguns não. Nas seções a se¬ 
guir, vamos concentrar-nos em algumas técnicas detalha¬ 
das que são utilizadas nos sistemas operacionais para pro¬ 
teger arquivos e outras coisas. Todas essas técnicas fazem 
uma distinção clara entre política (quais dados devem ser 
protegidos de quem) e mecanismo (como o sistema impõe 
a política). A separação entre política e mecanismo é dis¬ 
cutida em (Levin et ai, 1975). Nossa ênfase estará no me¬ 
canismo, não na política. Para material mais avançado, 
veja (Sandhu, 1993)- 

Em alguns sistemas, a proteção é imposta por um pro¬ 
grama chamado monitor de referência. Cada vez que é 


tentado um acesso a um recurso potencialmente protegi¬ 
do, o sistema primeiro exige que o monitor de referência 
verifique sua legalidade. 0 monitor de referência, então, 
olha em suas tabelas de políticas e toma uma decisão. A 
seguir, descreveremos o ambiente em que um monitor de 
referência opera. 

5.5.1 Domínios de Proteção 

Um sistema de computador contém muitos “objetos" 
que precisam ser protegidos. Esses objetos podem ser har¬ 
dware (p. ex., CPUs, segmentos de memória, unidades de 
disco ou impressoras) ou podem ser software (p. ex., pro¬ 
cessos, arquivos, bancos de dados ou semáforos). 

Cada objeto tem um nome único por meio do qual ele é 
referenciado e um conjunto limitado de operações que os 
processos têm permissão para executar. As operações read 
e WRiTE são apropriadas para um arquivo; up e DOWN fa¬ 
zem sentido em um semáforo. 

E óbvio que é necessário um meio de proibir que pro¬ 
cessos acessem objetos a que eles não têm acesso autoriza¬ 
do. Além disso, esse mecanismo também deve tornar possí¬ 
vel restringir os processos a um subconjunto das operações 
legais quando isso for necessário. Por exemplo, o processo 
A pode ser autorizado a ler, mas não a gravar, o arquivo F. 

Para discutir diferentes mecanismos de proteção, é útil 
apresentar o conceito de domínio. Um domínio é um con¬ 
junto de pares (objeto, direitos). Cada par especifica um 
objeto e algum subconjunto das operações que podem ser 
executadas nele. Um direito nesse contexto de permissão 
significa executar uma das operações. 

A Figura 5-22 mostra três domínios, mostrando os ob¬ 
jetos em cada domínio e os direitos (Read, Write eXecute - 
leitura, escrita, execução) disponíveis para cada objeto. Note 
que a Impressora 1 está em dois domínios ao mesmo tem¬ 
po. Embora não mostrado nesse exemplo, é possível o mes¬ 
mo objeto estar em múltiplos domínios, com diferentes di¬ 
reitos em cada um. 

A cada instante de tempo, cada processo executa em 
algum domínio de proteção. Em outras palavras, há uma 
coleção de objetos que ele pode acessar, e para cada objeto 
há um conjunto de direitos. Os processos também podem 
alternar de domínio para domínio durante a execução. As 
regras para comutação de domínio são bastante dependen¬ 
tes do sistema. 


Domínio 1 


Domínio 2 Domínio 3 



zArquivo3[R] , . 

Arquivo4[RWX]( Impressoral ^ Arquivo6[RWX] 

v Arquivo5ÍRW] „ 

v v ' Plotter2[W] 


Figura 5-22 Três domínios de proteção. 
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Para dar uma idéia mais concreta de domínio de prote¬ 
ção, vejamos o UNIX. No UNIX, o domínio de um processo é 
definido por seu uid e seu gid. Dada qualquer combinação 
(uid, gid), é possível fazer uma lista completa de todos os 
objetos (arquivos, incluindo dispositivos de E/S represen¬ 
tados por arquivos especiais, etc.) que podem ser acessados 
e se eles podem ser acessados para leitura, para gravação 
ou para execução. Dois processos com a mesma combina¬ 
ção {uid, gid) terão acesso exatamente ao mesmo conjun¬ 
to de objetos. Processos com valores {uid, gid) diferentes 
terão acesso a um conjunto diferente de arquivos, embora 
haja considerável sobreposição na maioria dos casos. 

Além disso, cada processo no UNIX tem duas metades: a 
parte do usuário e a parte do kernel. Quando o processo faz 
uma chamada de sistema, ele alterna da parte do usuário 
para a parte do kernel. A parte do kei'nel tem acesso a um 
conjunto de objetos diferente da parte do usuário. Por exem¬ 
plo, o kernel pode acessar todas as páginas na memória 
física, o disco inteiro e todos os outros recursos protegidos. 
Assim, uma chamada de sistema causa uma comutação de 
domínio. 

Quando um processo faz um EXEC em um arquivo com 
o bit SETUID ou SETGID ativado, ele adquire um novo uid 
ou um gid efetivo. Com uma combinação {uid, gid) dife¬ 
rente, ele tem um conjunto diferente de arquivos e de ope¬ 
rações disponíveis. A execução de um programa com SE- 


TUID ou SETGID é também uma comutação de domínio, 
uma vez que os direitos disponíveis agora são diferentes. 

Uma questão importante é como o sistema monitora 
quais objetos pertencem a qual domínio. Conceitualmen- 
te, pelo menos, pode-se conceber uma grande matriz, com 
as linhas sendo os domínios, e as colunas sendo os objetos. 
Cada elemento da matriz lista os direitos, se houver algum, 
que o domínio contém para o objeto. A matriz para a Figu¬ 
ra 5-22 é mostrada na Figura 5-23. Dados essa matriz e o 
número atual de domínio, o sistema pode dizer se é permi¬ 
tido um acesso a um dado objeto de uma maneira particu¬ 
lar a partir de um domínio especificado. 

A própria comutação de domínio pode facilmente ser 
incluída no modelo de matriz, percebendo que o domínio 
em si é um objeto, com a operação ENTER. A Figura 5-24 
mostra a matriz da Figura 5-23 novamente, só que agora 
com os três domínios como os objetos em si. Os processos 
no domínio 1 podem alternar para o domínio 2, mas uma 
vez lá, não podem voltar. Essa situação modela a execução 
de um programa SETUID no UNIX. Nenhuma outra alterna¬ 
ção de domínio é permitida nesse exemplo. 

5.5.2 Listas de Controle de Acesso 

Na prática, o annazenamento da matriz da Figura 5- 
24 raramente é feito, porque a matriz é grande e esparsa. A 
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Figura 5-23 Uma matriz de proteção. 
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Figura 5-24 Uma matriz de proteção com domínios como objetos. 



302 TANENBAUM & WOODHULL 


maioria dos domínios não tem nenhum acesso para a 
maioria dos objetos; então, armazenar uma matriz grande 
e na sua maior parte vazia é um desperdício de espaço em 
disco. Dois métodos que são práticos, entretanto, são ar¬ 
mazenar a matriz por linhas ou por colunas e, então, ar¬ 
mazenar somente os elementos não-vazios. As duas abor¬ 
dagens são surpreendentemente diferentes. Nesta seção, ve¬ 
remos armazenamento por coluna; na seguinte, estudare¬ 
mos armazenamento por linha. 

A primeira técnica consiste em associar a cada objeto 
uma lista (ordenada), contendo todos os domínios que po¬ 
dem acessar o objeto, e como. Essa lista é chamada lista 
de controle de acesso ou (ACL -Access List Control). 
Se fosse implementada no UNIX, a maneira mais fácil seria 
colocar a ACL para cada arquivo em um bloco separado de 
disco e incluir o número deste bloco no nó-i do arquivo. 
Como somente as entradas não-vazias da matriz são ar¬ 
mazenadas, o armazenamento total exigido para todas as 
ACLs combinadas é muito menor que a que seria necessá¬ 
ria para a matriz inteira. 

Como um exemplo de como as ACLs funcionam, va¬ 
mos continuar imaginando que elas sejam utilizadas no 
UNIX, onde um domínio é especificado por um par ( uid, 
gid). Realmente, as ACLs foram utilizadas no modelo do 
UNIX, o MUI.TICS, mais ou menos na maneira como descre¬ 
veremos, então, o exemplo não é tão hipotético. 

Vamos agora supor que temos quatro usuários (i. e., 
uids) Jan, Elsjelle e Maaike , que pertencem aos grupos 
sistema, staff, estudante e estudante, respectivamente. 
Suponha que alguns arquivos têm as seguintes ACLs: 

ArquivoO: (Jan, *, RWX) 

Arquivol: (Jan, sistema, RWX) 

Arquivo2: (Jan, *, RW-), (Eis, staff, RW-), (Maaike, *, 

RW-) 

Arquivo3: (*, estudante, R- -) 

Arquivo4: (Jelle, *, —), (*, estudante, R- -) 

Cada entrada de ACL, entre parênteses, especifica um uid, 
um gid e os acessos permitidos (Read, Write, eXecute - 
RWX). Um asterisco significa todos os uids ou gids. Arqui¬ 
voO poder ser lido, gravado ou executado por qualquer pro¬ 
cesso com uid = Jan e qualquer gz77. Arquivol poder ser 
acessado somente por processos com uid = Jan e gid = 
sistema. Um processo que tem uid = Jan egid = staff pode 
acessar ArquivoO, mas não Arquivol .Arquivo 2 poder ser 
lido ou gravado por processos com uid = Jan e qualquer 
gid, lido por processos com uid = Eis e gid = staff, ou por 
processos com uid = Maaike e qualquer gid. Arquivo3 
poder ser lido por qualquer aluno. Arquivo4 é especialmente 
interessante. Ele diz que qualquer pessoa com uid = Jelle, 
em qualquer grupo, não tem absolutamente nenhum aces¬ 
so, mas todos os outros alunos podem lê-lo. Utilizando ACLs, 
é possível proibir uids ou gids específicos de acessar um 
objeto, enquanto permite todas as outras pessoas na mes¬ 
ma classe. 

Bem, já falamos demais sobre o que o UNIX não faz. 
Agora vejamos o que ele realmente faz. Ele oferece três 
bits, rwx, por arquivo para o proprietário, o grupo do pro¬ 


prietário e os outros. Esse esquema é simplesmente a ACL 
novamente, mas compactada para 9 bits. Trata-se de uma 
lista associada com o objeto, dizendo quem pode acessá-la 
e como. Embora o esquema de 9 bits do UNIX seja nitida¬ 
mente menos geral que um sistema de ACL pleno, na prá¬ 
tica ele é adequado e sua implementação é muito mais 
simples e barata. 

0 proprietário de um objeto pode alterar sua ACL a qual¬ 
quer momento, tornando assim fácil proibir acessos que 
anteriormente eram permitidos. 0 único problema é que 
alterar a ACL mais provavelmente não afetará qualquer 
usuário que atualmente esteja utilizando o objeto (p. ex., 
que atualmente tem o arquivo aberto). 

5.5.3 Capacidades 

A outra maneira de cortar em fatias a matriz da Figura 
5-24 é por linhas. Quando esse método é utilizado, associ¬ 
ado com cada processo está uma lista de objetos que po¬ 
dem ser acessados, junto com uma indicação de quais ope¬ 
rações são permitidas em cada um, em outras palavras, 
seu domínio. Essa lista é chamada lista de capacitação, e 
os itens individuais dentro dela são chamados capacida¬ 
des (Dennis e Van Hom, 1966 ; Fabry, 1974). 

Uma típica lista de capacitação é mostrada na Figura 5- 
25. Cada capacidade tem um campo Tipo, que diz qual é 0 
tipo de um objeto, um campo Direitos, que é um mapa de 
bits, indicando quais das operações legais são permitidas 
para esse tipo de objeto e um campo Objeto, que é um pon¬ 
teiro para 0 próprio objeto (p. ex„ seu número de nó-i). As 
listas de capacitação são elas próprias objetos e podem ser 
apontadas por outra lista de capacitação, facilitando assim 
0 compartilhamento de subdomínios. As capacidades são 
freqüentemente referidas por sua posição na lista de capa¬ 
citação. Um processo poderia dizer: “Leia 1K do arquivo 
apontado por capacidade 2”. Essa forma de endereçamento 
é semelhante a utilizar descritores de arquivo no UNIX. 

É relativamente óbvio que as listas de capacitações ou 
listas C como freqüentemente são chamadas, devem ser 
protegidas contra alterações indevidas por parte do usuá¬ 
rio. Três métodos foram propostos para protegê-las. A pri¬ 
meira maneira requer uma arquitetura etiquetada, um 
projeto de hardware em que cada palavra de memória tem 
um bit extra (ou etiqueta) que diz se a palavra contém 
uma capacidade ou não. 0 bit de etiqueta não é utilizado 
por instruções aritméticas, de comparação, nem outras fun¬ 
ções comuns semelhantes e pode ser modificado somente 
por programas que executam no modo kernel (i. e., 0 sis¬ 
tema operacional). 

A segunda maneira é manter a lista C dentro do siste¬ 
ma operacional e simplesmente fazer os processos referir 
as capacidades por seu número de entrada, como mencio¬ 
nado anteriormente. 0 Hydra (Wulfe/ ai, 1974) trabalha¬ 
va dessa maneira. 

A terceira maneira é manter a lista C no espaço do usu¬ 
ário, mas criptografar cada capacidade com uma chave 
secreta desconhecida para 0 usuário. Essa abordagem é 
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# 

Tipo 

Direitos 

Objeto 

0 

File 

R— 

Ponteiro para Arquivo3 

1 

File 

RWX 

Ponteiro para Arquivo4 

2 

File 

RW- 

Ponteiro para Arquivoõ 

3 

Pointer 

-W- 

Ponteiro para Impressoral 


Figura 5-25 A lista de capacitação para o domínio 2 na Figura 5-23- 


particularmente adequada para sistemas distribuídos e é 
utilizada extensamente pelo Amoeba (Tanenbaum et ai , 
1990). 

Além dos direitos específicos dependentes do objeto, 
como leitura e execução, as capacidades normalmente têm 
direitos genéricos que são aplicáveis a todos os objetos. 
Exemplos de direitos genéricos são 

1. A capacidade de cópia: cria uma nova capacidade 
para o mesmo objeto. 

2. Copiar objeto: cria um objeto duplicado com uma 
nova capacidade. 

3. Remover capacidade: exclui uma entrada da lista 
C; não afeta o objeto. 

4. Destruir objeto: remove permanentemente um ob¬ 
jeto e uma capacidade. 

Uma última observação que merece ser feita sobre sis¬ 
temas de capacitação é que revogar acesso a um objeto é 
bastante difícil. É difícil para o sistema localizar todas as 
capacidades destacadas para qualquer objeto e tomá-las 
de volta, uma vez que elas podem estar armazenadas em 
listas C por todo o disco. Uma abordagem é ter cada capa¬ 
cidade apontando para um objeto indireto, em vez de para 
o próprio objeto. Por ter o objeto indireto apontando para o 
objeto real, o sistema sempre pode quebrar essa conexão, 
invalidando, assim, as capacidades. (Quando uma capaci¬ 
dade para o objeto indireto posteriormente é apresentada 
ao sistema, o usuário descobrirá que o objeto indireto ago¬ 
ra está apontando para um objeto nulo.) 

Outra maneira de obter revogação é o esquema utiliza¬ 
do no Amoeba. Cada objeto contém um número aleatório 
longo, que também está presente na capacidade. Quando 
uma capacidade é apresentada para utilização, os dois são 
comparados. Somente quando estão de acordo é que as 
operações são permitidas. 0 proprietário de um objeto pode 
solicitar que o número aleatório no objeto seja alterado, 
invalidando, dessa forma, capacidades existentes. Nenhum 
esquema permite revogação seletiva, isto é, tomar de volta, 
digamos, apenas a pennissão de um usuário em particular. 

5.5.4 Canais Secretos 

Mesmo com listas de controle de acesso e de capacita¬ 
ções, podem ocorrer vazamentos na segurança. Nesta se¬ 
ção, discutimos uma classe de problema. Tais idéias de¬ 
vem-se a Lampson (1973). 


0 modelo de Lampson envolve três processos e é princi¬ 
palmente aplicável a sistemas de compartilhamento de tem¬ 
po de grande porte. 0 primeiro processo é o cliente, o qual 
deseja que algum trabalho seja realizado pelo segundo, o 
servidor. 0 cliente e o servidor não confiam inteiramente 
um no outro. Por exemplo, o trabalho do servidor é ajudar 
clientes no preenchimento de seus formulários de impos¬ 
to. Os clientes estão preocupados com que o servidor regis¬ 
tre secretamente seus dados financeiros, por exemplo, man¬ 
tendo uma lista secreta de quem ganha quanto e, então, 
vender a lista. O servidor está preocupado com o fato de os 
clientes poderem tentar roubar o valioso programa de im¬ 
posto. 

0 terceiro processo é o colaborador, que, de fato, está 
conspirando com o servidor para roubar os dados confi¬ 
denciais do cliente. 0 colaborador e o servidor geralmente 
são possuídos pela mesma pessoa. Esses três processos são 
mostrados na Figura 5-26.0 objeto desse exercício é proje¬ 
tar um sistema em que é impossível para o servidor vazar 
para o colaborador as informações que legitimamente re¬ 
cebeu do cliente. Lampson chamou isso de problema do 
confinamento. 

Do ponto de vista do projetista de sistema, o objetivo é 
encapsular ou confinar o servidor de tal maneira que ele 
não possa passar as informações para o colaborador. Utili¬ 
zando um esquema de matriz de proteção, podemos facil¬ 
mente garantir que o servidor não possa comunicar-se com 
o colaborador por meio da gravação de um arquivo a que o 
colaborador tenha acesso de leitura. Provavelmente, tam¬ 
bém podemos assegurar que o servidor não possa comuni¬ 
car-se com o colaborador, utilizando o mecanismo de co¬ 
municação interprocessos do sistema. 

Infelizmente, podem estar disponíveis canais mais su¬ 
tis de comunicação. Por exemplo, o servidor pode tentar 
comunicar um fluxo binário de bits como segue. Para en¬ 
viar um bit 1, ele trabalha o máximo que pode por um 
intervalo fixo de tempo. Para enviar um bit 0, ele vai dor¬ 
mir pelo mesmo intervalo de tempo. 

0 colaborador pode tentar detectar o fluxo de bits por 
meio do cuidadoso monitoramento do seu tempo de res¬ 
posta. Em geral, ele obterá melhor resposta quando o ser¬ 
vidor estiver enviando um 0 do que quando o senador esti¬ 
ver enviando um 1. Esse canal de comunicação é conheci¬ 
do como um canal secreto (covert channel) e é ilustrado 
na Figura 5-26 (b) 



304 TANENBAUM & W00DHULL 


Cliente Servidor Colaborador Servidor encapsulado 



(a) (b) 

Figura 5-26 (a) Os processos do cliente, do servidor e do colaborador, (b) 0 servidor encapsulado ainda pode 

vazar para o colaborador via canais secretos. 


Naturalmente, o canal secreto é um canal com muito 
ruído, contendo muitas informações estranhas, mas as in¬ 
formações de confiança podem ser enviadas por um canal 
ruidoso, utilizando um código para correção de erros (p. 
ex., um código de Hamming ou algo até mais sofisticado). 
0 uso de um código para correção de erros reduz a largura 
de banda, já baixa, do canal secreto ainda mais, mas ain¬ 
da pode ser suficiente para vazar informações substanci¬ 
ais. É relativamente óbvio que nenhum modelo de prote¬ 
ção baseado em uma matriz de objetos e de domínios im¬ 
pedirá esse tipo de vazamento. 

Modular o uso da CPU não é o único canal secreto. A 
taxa de paginação também pode ser modulada (muitas 
falhas de página para um 1, nenhuma falha de página 
para um 0). De fato, quase qualquer maneira de degradar 
o desempenho do sistema de modo temporizado é candi¬ 
data. Se o sistema oferecer uma maneira de bloquear ar¬ 
quivos, então, o servidor pode bloquear algum arquivo para 
indicar um 1, e desbloquear para indicar um 0. Em alguns 
sistemas, é possível um processo detectar o status de um 
bloqueio mesmo em um arquivo que ele não pode acessar. 

Adquirir e liberar recursos dedicados (unidades de fita, 
plotadoras, etc.) também pode ser utilizado para sinalizar. 
0 servidor adquire o recurso para enviar um 1 e libera-o 
para enviar um 0. No UNIX, o servidor poderia criar um 
arquivo para indicar um 1 e removê-lo para indicar um 0: 
o colaborador poderia utilizar a chamada de sistema AC¬ 
CESS para ver se o arquivo existe. Essa chamada funciona 
mesmo que o colaborador não tenha nenhuma permissão 
para utilizar o arquivo. Infelizmente existem muitos ou¬ 
tros canais secretos. 

Lampson também menciona uma maneira de vazar as 
informações para o proprietário (humano) do processo de 
servidor. Presumivelmente o processo de servidor será inti¬ 
tulado a dizer a seu proprietário quanto trabalho fez em 
favor do cliente; então, o cliente pode ser cobrado. Se a conta 
real do cálculo for, digamos, 100 dólares e a renda do cli¬ 
ente é 53K de dólares os servidores poderiam informar a 
conta como 100,53 para seu proprietário. 

Simplesmente localizar todos os canais secretos, dei¬ 
xando de lado a ação de bloqueá-los, é extremamente difí¬ 


cil. Na prática, há pouco que pode ser feito. Introduzir um 
processo que causa falhas de página aleatoriamente ou, de 
outro modo, que gasta seu tempo degradando o desempe¬ 
nho do sistema a fim de reduzir a largura de banda dos 
canais secretos não é uma proposta atraente. 

5.6 VISÃO GERAL DO SISTEMA DE 
ARQUIVOS DO MINIX 

Como qualquer sistema de arquivos, o sistema de ar¬ 
quivos do MiNix deve lidar com todas as questões que aca¬ 
bamos de estudar. Ele deve alocar e desalocar espaço para 
arquivos, monitorar blocos de disco e liberar espaço, ofere¬ 
cer alguma maneira de proteger arquivos contra uso não- 
autorizado e assim por diante. No restante deste capítulo, 
vamos aprofundar-nos no MINIX para ver como ele realiza 
esses objetivos. 

Na primeira parte deste capítulo, repetidamente referi- 
mo-nos ao UNIX em vez de ao mixix por generalidade, em¬ 
bora a interface externa dos dois seja praticamente idênti¬ 
ca. Agora nos concentraremos no projeto interno do MINIX. 
Para as informações sobre aspectos internos do UNIX, veja 
Thompson (1978), Bach (1987), Lions (1996) e Vahalia 
(1996). 

O sistema de arquivos do minix é somente um grande 
programa em C que executa no espaço do usuário (veja a 
Figura 2-26). Para ler e para gravar arquivos, os processos 
de usuário enviam mensagens para o sistema de arquivos 
dizendo o que eles querem que seja feito. O sistema de ar¬ 
quivos faz o trabalho e, então, envia de volta uma resposta. 
O sistema de arquivos é, de fato, um servidor de arquivos 
de rede que está executando na mesma máquina que o 
chamador. 

Esse projeto tem algumas implicações importantes. De 
um lado, o sistema de arquivos pode ser modificado, expe¬ 
rimentado e testado quase completamente independente 
do restante do MINIX. Por outro, é muito fácil mover o siste¬ 
ma de arquivos inteiro para qualquer computador que te¬ 
nha um compilador C, compilá-lo aí e utilizá-lo como um 
servidor remoto independente de arquivos UNIX. As únicas 
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alterações que precisam ser feitas estão na área de como as 
mensagens são enviadas e recebidas, que difere de sistema 
para sistema. 

Nas seções a seguir, apresentaremos uma visão geral de 
muitas das áreas-chaves do projeto do sistema de arquivos. 
Especificamente, veremos as mensagens, o arranjo do sis¬ 
tema de arquivos, os mapas de bits, nós-i, o cache de blo¬ 
cos, os diretórios e caminhos, os descritores de arquivo, o 
bloqueio de arquivo e os arquivos especiais (mais canali¬ 
zações). Depois que estudarmos todos esses temas, mostra¬ 
remos um exemplo simples de como os pedaços ajustam- 
se entre si, rastreando o que acontece quando um processo 
de usuário executa a chamada de sistema READ. 

5.6.1 Mensagens 

0 sistema de arquivos aceita 39 tipos de mensagens que 
solicitam trabalho. Todas exceto duas são para chamadas 
de sistema MINIX. As duas exceções são mensagens geradas 
por outras partes do MINIX. Das chamadas de sistema, 31 
são aceitas de processos de usuário. Seis mensagens de cha¬ 
mada de sistema são para chamadas de sistema tratadas 
primeiro pelo gerenciador de memória que, então, chama 
o sistema de arquivos para fazer uma parte do trabalho. 
Duas outras mensagens também são processadas pelo sis¬ 
tema de arquivos. As mensagens são mostradas na Figura 
5-27. 

A estrutura do sistema de arquivos é basicamente a 
mesma do gerenciador de memória e de todas as tarefas de 
E/S. Ele tem um laço principal que espera uma mensagem 
chegar; quando uma mensagem chega, seu tipo é extraído 
e utilizado como um índice em uma tabela de ponteiros 
que contém os procedimentos dentro do sistema de arqui¬ 
vos que tratam todos os tipos. Então, o procedimento apro¬ 
priado é chamado, faz seu trabalho e retorna um valor de 
status. 0 sistema de arquivos, então, envia de volta uma 
resposta ao chamador e volta para o topo do laço, esperan¬ 
do a próxima mensagem. 

5.6.2 Arranjo do Sistema de Arquivos 

Um sistema de arquivos MINIX é uma entidade lógica 
autocontida com nós-i, com diretórios e com blocos de da¬ 
dos. Pode ser armazenado em qualquer dispositivo de blo¬ 
co, como um disquete ou (parte de) um disco rígido. Em 
todos os casos, o arranjo do sistema de arquivos tem a mes¬ 
ma estrutura. A Figura 5-28 mostra esse arranjo para um 
disquete de 360K com 128 nós-i e um tamanho de bloco de 
1K. Sistemas de arquivos maiores, ou aqueles com mais ou 
menos nós-i ou um tamanho de bloco diferente, terão os 
mesmos seis componentes na mesma ordem, mas seus ta¬ 
manhos relativos podem ser diferentes. 

Cada sistema de arquivos começa com um bloco de 
inicialização. Esse contém código executável. Quando o 
computador é ligado, o hardware lê o bloco de inicializa¬ 
ção do dispositivo de inicialização para a memória, salta 
para ele e começa a executar seu código. 0 código do bloco 


de inicialização começa o processo de carregamento do sis¬ 
tema operacional em si. Uma vez que o sistema foi inicia- 
lizado, o bloco de inicialização não é mais utilizado. Nem 
toda unidade de disco pode ser utilizada como um disposi¬ 
tivo de inicialização, mas mantendo a estrutura uniforme, 
cada dispositivo de blocos tem um bloco reservado para o 
código do bloco de inicialização. Na pior das hipóteses, essa 
estratégia desperdiça um bloco. Para impedir que o har¬ 
dware tente inicializar um dispositivo não-inicializável um 
número mágico é colocado em uma posição conhecida 
no bloco de inicialização quando e somente quando o có¬ 
digo executável é gravado no dispositivo. Quando iniciali¬ 
za de um dispositivo, o hardware (na realidade, o código 
de BIOS) irá recusar-se a tentar carregar de um dispositivo 
em que falta o número mágico. Fazendo isso, previne-se 
que lixo seja inadvertidamente utilizado como um progra¬ 
ma de inicialização. 

0 superbloco contém as informações que descrevem 
o arranjo do sistema de arquivos. Ele é ilustrado na Figura 
5-29- A principal função do superbloco é dizer ao sistema 
de arquivos o tamanho dos vários pedaços que compõem 
tal sistema. Dados o tamanho de bloco e o número de nós- 
i, é fácil calcular o tamanho do mapa de bits de nós-i e o 
número de blocos de nós-i. Por exemplo, para um bloco de 
1K, cada bloco do mapa de bits tem 1K bytes (8K bits) e 
assim podem monitorar o status de até 8192 nós-i. (Real¬ 
mente o primeiro bloco pode tratar somente até 8191 nós- 
i, uma vez que não há um nó-i 0 (zero), mas é fornecido 
um bit no mapa de bits, de qualquer maneira.) Para 10.000 
nós-i, dois blocos de mapa de bits são necessários. Uma vez 
que cada nó-i ocupa 64 bytes, um bloco de 1K armazena 
até 16 nós-i. Com 128 nós-i utilizáveis, 8 blocos de disco 
são necessários para conter todos. 

Explicaremos a diferença entre zonas e blocos detalha¬ 
damente mais adiante, mas por enquanto é suficiente di¬ 
zer que o espaço em disco pode ser alocado em unidades 
(zonas) de 1, 2,4, 8 ou em geral 2" blocos. 0 mapa de bits 
de zonas monitora o espaço livre em zonas, não em blocos. 
Para todos os disquetes-padrão utilizados pelo MINIX, os 
tamanhos de blocos e de zonas são os mesmos (1K); por¬ 
tanto, para uma primeira abordagem, uma zona é o 
mesmo que um bloco nesses dispositivos. Até chegarmos 
aos detalhes da alocação de espaço mais adiante no capí¬ 
tulo, é adequado pensar “bloco” sempre que você ver 
“zona”. 

Note que o número de blocos por zona não é armaze¬ 
nado no superbloco, uma vez que ele nunca é necessário. 
Ilido o que é necessário é logaritmo de base 2 da zona para 
proporção de bloco, que é utilizado como contagem de des¬ 
locamento para converter blocos em zonas e vice-versa. Por 
exemplo, com 8 blocos por zona, log 2 8 = 3, portanto, para 
localizar a zona que contém o bloco 128, deslocamos 128 
para a direita 3 bits a fim de obter a zona 16 . 

O mapa de bits de zonas inclui somente as zonas de 
dados (i. e., os blocos utilizados para os mapas de bit e nós- 
i não estão no mapa), com a primeira zona de dados de¬ 
signada zona 1 no mapa de bits. Como com o mapa de bits 



306 TANENBAUM & WOODHULL 


Mensagens dos usuários 

Parâmetros de entrada 

Valor da resposta 

ACCESS 

Nome do arquivo, modo de acesso 

Status 

CHDIR 

Nome do novo diretório de trabalho 

Status 

CHMOD 

Nome do arquivo, novo modo 

Status 

CHOWN 

Nome do arquivo, novo proprietário, grupo 

Status 

CHROOT 

Nome do novo diretório-raiz 

Status 

CLOSE 

Descritor de arquivo do arquivo a ser fechado 

Status 

CREAT 

Nome do arquivo a ser criado, modo 

Descritor de arquivo 

DUP 

Descritor de arquivo (para dup2, dois fds) 

Novo descritor de arquivo 

FCNTL 

Descritor de arquivo, código de função, arg 

Depende da função 

FSTAT 

Nome do arquivo, buffer 

Status 

IOCTL 

Descritor de arquivo, código de função, arg 

Status 

LINK 

Nome do arquivo a vincular, nome do vínculo 

Status 

LSEEK 

Descritor de arquivo, deslocamento, de onde 

Nova posição 

MKDIR 

Nome do arquivo, modo 

Status 

MKNOD 

Nome de dir ou modo especial, endereço 

Status 

MOUNT 

Arquivo especial, onde montar, sinalizador de ro 

Status 

OPEN 

Nome do arquivo a abrir, sinalizador de r/w 

Descritor de arquivo 

PIPE 

Ponteiro para 2 descritores de arquivo (modificado) 

Status 

READ 

Descritor de arquivo, buffer, quantos bytes 

# Bytes lidos 

RENAME 

Nome do arquivo, nome do arquivo 

Status 

RMDIR 

Nome do arquivo 

Status 

STAT 

Nome do arquivo, buffer de status 

Status 

STIME 

Ponteiro para tempo atual 

Status 

SYNC 

(Nenhum) 

Sempre OK 

TIME 

Ponteiro para onde colocar o tempo atual 

Status 

TIMES 

Ponteiro para buffer de tempos do processo e do filho 

Status 

UMASK 

Complemento de máscara de modo 

Sempre OK 

UMOUNT 

Nome do arquivo especial para desmontar 

Status 

UNLINK 

Nome do arquivo para desvincular 

Status 

UTIME 

Nome do arquivo, tempos do arquivo 

Sempre OK 

WRITE 

Descritor do arquivo, buffer, quantos bytes 

# Bytes gravados 

Mensagens do MM 

Parâmetros de entrada 

Valor da resposta 

EXEC 

Pid 

Status 

EXIT 

Pid 

Status 

FORK 

Pid do pai, pid do filho 

Status 

SETGID 

Pid, gid real e efetivo 

Status 

SETSID 

Pid 

Status 

SETUID 

Pid, uid real e efetivo 

Status 

Outras mensagens 

Parâmetros de entrada 

Valor da resposta 

REVIVE 

Processo a reanimar 

(Nenhuma resposta) 

UNPAUSE 

Processo a verificar 

(Veja texto) 


Figura 5-27 As mensagens do sistema de arquivos. Os parâmetros do nome de arquivo são sempre ponteiros para o nome. 0 código 
de status como valor de resposta significa OK ou ERROR. 
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Bloco de Super- 
inicialização bloco 


u 


Nós-i 


Um bloco de disco 


3 


Dados 


Mapa de bits 
de nós-i 


Mapa de bits 
de zonas 


Figura 5-28 0 arranjo de disco para o disco mais simples: um disquete de 360K.com 128 nós-i e um tamanho 
de bloco de 1K (i. e., dois setores de 512 bytes consecutivos são tratados como um único bloco). 


de nós-i, o bit 0 no mapa não é utilizado; então, o primeiro 
bloco no mapa de bits de zonas pode mapear 8191 zonas e 
blocos subseqüentes podem mapear 8192 zonas cada um. 
Se examinar os mapas de bits em um disco recentemente 
formatado, você descobrirá que tanto os mapas de bit de 
nó-i como de zonas têm 2 bits configurados como 1. Um é 
para 0 nó-i 0 ou zona 0 (inexistentes); 0 outro épara 0 nó- 
i e a zona, utilizados pelo diretório-raiz no dispositivo, que 
é colocado aí quando 0 sistema de arquivos é criado. 


As informações no superbloco são redundantes porque, 
às vezes, elas são necessárias de uma forma e, às vezes, de 
outra. Com 1K dedicado ao superbloco, faz sentido compu¬ 
tar essas informações em todas as formas que sejam neces¬ 
sárias, em vez de ter de recomputá-las freqüentemente du¬ 
rante a execução. O número de zona da primeira zona de 
dados no disco, por exemplo, pode ser calculado a partir do 
tamanho de bloco, tamanho da zona, número de nós-i e 
número de zonas, mas e' mais rápido simplesmente man- 


Presente 
em disco 
e na 
memória 


Presente 
na memória 
mas não 
em disco 


Número de nós 

Número de zonas (VI) 

Número de blocos de mapas de bits de nós-i 

Número de blocos de mapas de bits de zonas 

Primeira zona de dados 

Log2 (bloco/zona) 

Tamanho máximo de arquivo 

Número mágico 

Preenchimento 

Número de zonas (V2) 

Ponteiro para nó-i da raiz do 
sistema de arquivos montado 

Ponteiro para nó-i montado 

Nós-i/bloco 

Número de dispositivo 

Sinalizador para somente leitura 

Sinalizador big-endian do sistema de arquivos 

Versão do sistema de arquivos 

Zonas diretas/nós-i 

Zonas indiretas/bloco indireto 

Primeiro bit livre no mapa de bits de nó-i 

Primeiro bit livre no mapa de bits de zonas 


Figura 5-29 0 superbloco do MINIX. 



308 TANENBAUM & WOODHULL 


tê-lo no superbloco. 0 restante do superbloco é desperdiça¬ 
do de qualquer modo, portanto, utilizar outra palavra dele 
não custa nada. 

Quando o minix é inicializado, o superbloco para o dis- 
positivo-raiz é carregado em uma tabela na memória. De 
maneira semelhante, de acordo como outros sistemas de 
arquivos são montados, seus superblocos também são tra¬ 
zidos para a memória. A tabela do superbloco armazena 
alguns campos ausentes no disco. Esses incluem sinaliza¬ 
dores que permitem que o acesso a um dispositivo seja es¬ 
pecificado como apenas de leitura ou como seguindo uma 
convenção de ordem de bytes oposta ao padrão e campos 
para acelerar o acesso, indicando pontos nos mapas de bits 
abaixo dos quais todos os bits são marcados como utiliza¬ 
dos. Além disso, há um campo que descreve o dispositivo 
do qual o superbloco veio. 

Antes de um disco poder ser utilizado como um sistema 
de arquivos minix, ele deve receber a estrutura de dados da 
Figura 5-28. 0 programa utilitário mkfs foi oferecido para 
construir sistemas de arquivos. Esse programa tanto pode 
ser chamado por um comando do tipo 

mkfs/dev/fdl 1440 

para construir um sistema de arquivos vazio de 1440 blo¬ 
cos no disquete na unidade 1, como pode receber um ar¬ 
quivo de protótipo, listando diretórios e arquivos para in¬ 
cluir no novo sistema de arquivos. Esse comando também 
coloca um número mágico no superbloco para identificar 
o sistema de arquivos como um sistema de arquivos minix 
válido. O sistema de arquivos MINIX desenvolveu-se e al¬ 
guns aspectos do sistema de arquivos (p. ex., o tamanho 
dos nós-i) eram diferentes em versões anteriores. 0 núme¬ 
ro mágico identifica a versão de mkfs que criou o sistema 
de arquivos, de modo que as diferenças podem ser ajusta¬ 
das. Tentativas de montar um sistema de arquivos que não 
no formato MINIX, como um disquete MS-DOS, serão rejei¬ 
tadas pela chamada de sistema mount, que verifica o su¬ 
perbloco para um número mágico válido e outras coisas. 

5.6.3 Mapas de Bits 

0 MINIX monitora quais nós-i e quais zonas estão livres 
utilizando dois mapas de bits (veja Figura 5-29). Quando 
um arquivo é removido, então, é uma simples questão de 
calcular qual bloco do mapa de bits contém o bit para o 
nó-i sendo liberado e a localizá-lo, utilizando o mecanis¬ 
mo normal de cache. Uma vez que o bloco foi localizado, o 
bit correspondente ao nó-i liberado é configurado como 0. 
As zonas são liberadas do mapa de bits de zonas da mesma 
maneira. 

Logicamente, quando um arquivo está para ser criado, 
o sistema de arquivos deve pesquisar o primeiro nó-i livre 
pelos blocos do mapa de bits um por vez. Esse nó-i, então, 
é alocado para o novo arquivo. De fato, a cópia na memó¬ 
ria do superbloco tem um campo que aponta para o pri¬ 
meiro nó-i livre; então, nenhuma pesquisa é necessária até 
depois que um nó for utilizado, quando o ponteiro deve ser 


atualizado para apontar para o novo próximo nó-i livre, o 
qual freqüentemente será o seguinte ou um próximo. De 
maneira semelhante, quando um nó-i é liberado, uma ve¬ 
rificação é feita para ver se o nó-i livre vem antes do atual¬ 
mente apontado; e o ponteiro é atualizado se necessário. 
Se cada entrada de nó-i no disco estiver cheia, a rotina de 
pesquisa retornará um 0, que é a razão por que o nó-i 0 
não é utilizado (i. e., para que ele possa ser utilizado para 
indicar a falha na pesquisa). (Quando mkfs cria um novo 
sistema de arquivos, ele zera o nó-i 0 e configura o bit mais 
baixo no mapa de bits como 1, de modo que o sistema de 
arquivos nunca tentará alocá-lo.) Uido o que foi dito aqui 
sobre os mapas de bits de nós-i também se aplica ao mapa 
de bits de zonas; logicamente ele é pesquisado quanto à 
primeira zona livre quando espaço é necessário, mas um 
ponteiro para a primeira zona livre é mantido para elimi¬ 
nar a maior parte da necessidade de pesquisas seqüenciais 
pelo mapa de bits. 

Com essa fundamentação, agora podemos explicar a 
diferença entre zonas e blocos. A idéia por trás das zonas é 
ajudar a assegurar que blocos de disco pertencentes ao 
mesmo arquivo estejam localizados no mesmo cilindro, 
melhorando o desempenho quando o arquivo é lido seqüen- 
cialmente. A abordagem escolhida é tornar possível alocar 
diversos blocos por vez. Se, por exemplo, o tamanho de um 
bloco for de 1K e o tamanho de zona for de 4K, o mapa de 
bits de zonas irá monitorar zonas, não blocos. Um disco de 
20M tem 5K zonas de 4K, daí 5K bits em seu mapa de zo¬ 
nas. 

A maior parte do sistema de arquivos trabalha com blo¬ 
cos. As transferências de disco são sempre um bloco por 
vez, e o cache também trabalha com blocos individuais. 
Somente algumas partes do sistema que monitoram ende¬ 
reços físicos de disco (p. ex., o mapa de bits de zonas e os 
nós-i) têm conhecimento das zonas. 

Algumas decisões de projeto tiveram de ser feitas ao de- 
senvolver-se o sistema de arquivos do minix. Em 1985, quan¬ 
do o MINIX foi concebido, as capacidades de disco eram pe¬ 
quenas, e acreditava-se que a maioria dos usuários teria 
somente disquetes. Uma decisão foi tomada para restringir 
endereços de disco para 16 bits no sistema de arquivos VI, 
principalmente para ser capaz de armazenar muitos deles 
nos blocos indiretos. Com um número de zona de 16 bits e 
uma zona de 1K, apenas 64K de zonas podem ser endere¬ 
çadas, limitando os discos a 64 M. Isso era um espaço enor¬ 
me de armazenamento naquela época e pensou-se que à 
medida que os discos aumentassem, seria fácil alternar para 
zonas de 2K ou de 4K, sem alterar o tamanho do bloco. Os 
números de zona de 16 bits também tornaram fácil man¬ 
ter o tamanho dos nós-i em 32 bytes. 

À medida que o MINIX desenvolvia-se, e os discos maio¬ 
res tornavam-se cada vez mais comuns, tornou-se óbvio 
que alterações eram desejáveis. Muitos arquivos são me¬ 
nores que 1K, então, aumentar o tamanho de bloco signi¬ 
ficaria desperdiçar largura de banda de disco, lendo e gra¬ 
vando principalmente blocos vazios e desperdiçando pre¬ 
ciosa memória principal, armazenando-os no cache. O ta- 



SISTEMAS OPERACIONAIS 309 


manho da zona poderia ter sido aumentado, mas um ta¬ 
manho de zona maior significa mais espaço em disco des¬ 
perdiçado e era ainda desejável manter uma operação efi¬ 
ciente em discos pequenos. Outra alternativa razoável se¬ 
ria ter tamanhos diferentes de zona de acordo com o tama¬ 
nho dos dispositivos. 

No fim, decidiu-se aumentar o tamanho dos ponteiros 
de disco para 32 bits. Isso torna possível o sistema de arqui¬ 
vos MiNix V2 lidar com tamanhos de dispositivo de ate' 4 
terabytes com blocos e zonas de 1K. Em parte, essa decisão 
baseou-se em outras decisões sobre o que deve estar no nó- 
i, o que tornou razoável aumentar o tamanho do nó-i para 
64 bytes. 

As zonas tambe'm introduzem um problema inespera¬ 
do, melhor ilustrado por um exemplo simples, novamente 
com zonas de 4K e blocos de 1K. Suponha que um arquivo 
tenha 1K de comprimento, o que significa que 1 zona foi 
alocada para ele. Os blocos entre 1K e 4K contêm lixo (re¬ 
síduo do proprietário anterior), mas nenhum dano é cau¬ 
sado porque o tamanho de arquivo claramente é marcado 
no nó-i como 1K. De fato, os blocos contendo lixo não se¬ 
rão lidos no cache de blocos, uma vez que as leituras são 
feitas por blocos, não por zonas. As leituras além do fim de 
um arquivo sempre retornam uma contagem de 0 e ne¬ 
nhum dado. 

Agora alguém move para 32768 e grava 1 byte. 0 tama¬ 
nho do arquivo agora é alterado para 32769. Movimentos 
subseqüentes para 1K seguidos por tentativas de ler os da¬ 
dos agora serão capazes de ler o conteúdo anterior do blo¬ 
co, uma importante falha na segurança. 

A solução é verificar essa situação quando uma grava¬ 
ção é feita além do fim de um arquivo e explicitamente 
zerar todos os blocos que ainda não foram alocados na zona 
que era antes a última. Embora essa situação raramente 
ocorra, o código precisa lidar com ela, o que torna o siste¬ 
ma ligeiramente mais complexo. 

5.6.4 Nós-i 

0 leiaute do nó-i do minix é dado na Figura 5-30. Ele é 
quase o mesmo de um nó-i padrão do UNIX. Os ponteiros 
de zona de disco são de 32 bits e há somente 9 ponteiros, 7 
diretos e 2 indiretos. Os nós-i do MINIX ocupam 64 bytes, o 
mesmo que os nós-i padrão do UNIX e há espaço disponível 
para um 10° (triplo indireto) ponteiro, embora sua utili¬ 
zação não seja suportada pela versão padrão do sistema de 
arquivos. Os tempos de acesso, de modificação e de altera¬ 
ção do nó-i no minix são padrão, como no UNIX. O último 
destes é atualizado para quase cada operação de arquivo 
exceto para uma leitura do arquivo. 

Quando um arquivo é aberto, seu nó-i é localizado e 
carregado na tabela inode na memória, onde permanece 
até que o arquivo seja fechado. A tabela inode tem alguns 
campos adicionais não-presentes no disco, como o núme¬ 
ro e o dispositivo do nó-i; então, o sistema de arquivos sabe 
onde regravar se ele for modificado enquanto na memó¬ 
ria. Ela também tem um contador por nó-i. Se o mesmo 


arquivo for aberto mais de uma vez, somente uma cópia 
do nó-i é mantida na memória, mas o contador é incre¬ 
mentado cada vez que o arquivo é aberto, e decrementado 
cada vez que o arquivo é fechado. Somente quando o con¬ 
tador por fim alcança zero é que o nó-i é removido da tabe¬ 
la. Se foi modificado desde que foi carregado na memória, 
ele também é regravado no disco. 

A função principal de um nó-i de arquivo é informar 
onde os blocos de dados estão. Os primeiros sete números 
de zona são dados diretamente no próprio nó-i. Para a dis¬ 
tribuição padrão, com zonas e blocos de 1K, arquivos até 
7K não necessitam de blocos indiretos. Além de 7K, zonas 
indiretas são necessárias, utilizando o esquema da Figura 
5-10, exceto que somente blocos simples e indiretos duplos 
são utilizados. Com blocos e zonas de 1K e números de 
zona de 32 bits, um bloco indireto simples armazena 256 
entradas, o que representa um quarto de megabyte de ar¬ 
mazenamento. O bloco indireto duplo aponta para 256 blo¬ 
cos indiretos simples, dando acesso a até 64 megabytes. 0 
tamanho máximo de um sistema de arquivos MINIX é de 1 
G, portanto uma modificação para utilizar o bloco indire¬ 
to triplo ou tamanhos maiores de zona poderia ser útil se 
fosse desejável acessar arquivos muito grandes em um sis¬ 
tema MINIX. 

0 nó-i também armazena as informações de modo, que 
dizem qual é o tipo de um arquivo (comum, diretório, de 
bloco especial, de caractere especial, canalização) e dá os 
bits de proteção, SETUTD e SETGID. O campo número de vín¬ 
culos no nó-i registra quantas entradas de diretório apon¬ 
tam para o nó-i, então, o sistema de arquivos sabe quando 
liberar o armazenamento do arquivo. Esse campo não deve 
ser confundido com o contador (presente somente na ta¬ 
bela inode na memória, não no disco) que diz quantas 
vezes o arquivo está atualmente aberto, geralmente por 
processos diferentes. 

5.6.5 Cache de Blocos 

O minix utiliza um cache de blocos para melhorar o 
desempenho do sistema de arquivos. O cache é implemen¬ 
tado como uma matriz de buffers, cada um consistindo em 
um cabeçalho contendo ponteiros, contadores e sinaliza¬ 
dores, e um corpo com lugar para um bloco de disco. To¬ 
dos os buffers que não estão em utilização são encadeados 
juntos em uma lista duplamente encadeada, do mais re¬ 
centemente utilizado (MRU) para o menos recentemente 
utilizado (LRU), como ilustrado na Figura 5-31- 

Além disso, para ser capaz de rapidamente determinar 
se um dado bloco está no cache ou não, uma tabela de 
hash é utilizada. Todos os buffers contendo um bloco que 
tem código de hash k estão encadeados juntos em uma lis¬ 
ta encadeada simples apontada pela entrada k na tabela de 
hash. A função de hash simplesmente extrai os n bits de 
ordem inferior do número do bloco, portanto blocos de dis¬ 
positivos diferentes aparecem na mesma cadeia de hash. 
Cada buffer está em uma dessas cadeias. Quando o sistema 
de arquivos é inicializado depois que o MINIX é inicializa- 
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16 bits 


64 bytes 


Modo 

Número de vínculos 

Uid 

Gid 

- Tamanho do arquivo 

- Tempo de acesso 

- Tempo de modificação 

- Tempo de alteração de status 

- Zona 0 

- Zona 1 

- Zona 2 

- Zona 3 

- Zona 4 

- Zona 5 

- Zona 6 

- Zona indireta 

- Zona indireta dupla 

- Não-utilizada 


■ Tipo do arquivo e bits rwx 

■ Entradas de diretório para esse arquivo 
• Identifica usuário que possui o arquivo 

- Grupo do proprietário 

- Número de bytes no arquivo 


Todos os tempos são em segundos 
desde 1 s de Janeiro de 1970 


Números de zona para as primeiras sete 
zonas de dados no arquivo 


Utilizado para arquivos maiores que 7 zonas 


(Poderia ser utilizado para zona indireta tripla) 


Figura 5-30 0 nó-i do MINIX. 


Frente Fundo 



Figura 5-31 As listas encadeadas utilizadas pelo cache de blocos. 
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do, todos os buffers não estão em uso, naturalmente, e to¬ 
dos estão em uma única cadeia apontada pela entrada 0 
da tabela de hash. Nesse momento todas as outras entradas 
da tabela de hash contêm um ponteiro nulo, mas uma vez 
que o sistema inicia, os buffers serão removidos da cadeia 
0 e outras cadeias serão construídas. 

Quando o sistema de arquivos necessita de um bloco, 
ele chama um procedimento, get_block, que computa o 
código de hash para esse bloco e pesquisa a lista apropria¬ 
da. Get_block é chamado com um número de dispositivo 
assim como um número de bloco, e a pesquisa compara 
ambos os números com os campos correspondentes na ca¬ 
deia de buffers. Se um buffer que contém o bloco é locali¬ 
zado, um contador no cabeçalho do buffer é incrementado 
para mostrar que o bloco está em uso, e um ponteiro para 
ele é retornado. Se um bloco não é localizado na lista de 
hash , o primeiro buffer na lista de LRU pode ser utilizado; 
não é garantido estar ainda em utilização, e o bloco que 
contém pode ser expulso para liberar o buffer. 

Uma vez que um bloco foi escolhido para expulsão, 
outro sinalizador em seu cabeçalho é verificado para ver se 
o bloco foi modificado desde que foi lido. Se tiver sido, ele é 
regravado no disco. Nesse ponto, o bloco necessário é lido 
mediante o envio de uma mensagem à tarefa de disco. 0 
sistema de arquivos é suspenso até que o bloco chegue, 
momento em que ele continua, e um ponteiro para o bloco 
é retornado para o chamador. 

Quando o procedimento que solicitou o bloco comple¬ 
tar seu trabalho, chama outro procedimento, put_block, 
para liberar o bloco. Normalmente, um bloco será utiliza¬ 
do imediatamente e, então, liberado, mas uma vez que é 
possível que solicitações adicionais para um bloco sejam 
feitas antes de ele ser liberado, put_block decrementa o 
contador de uso e coloca o buffer de volta na lista de LRU 
somente quando o contador de uso voltar a zero. Enquan¬ 
to o contador não for zero, o bloco permanece no limbo. 

Um dos parâmetros para put_block informa qual clas¬ 
se de bloco (p. ex., nós-i, diretório, dados) está sendo libe¬ 
rada. Dependendo da classe, duas decisões-chaves são fei¬ 
tas: 

1. Colocar o bloco na frente ou no fundo da lista de 
LRU. 

2. Gravar o bloco (se modificado) para disco, imedi¬ 
atamente ou não. 

Os blocos que podem não ser necessários novamente em 
seguida, como superblocos, vão na frente da lista para que 
sejam reivindicados da próxima vez que um buffer livre for 
necessário. Todos os outros blocos vão no fundo da lista no 
verdadeiro estilo LRU. 

Um bloco modificado não é regravado até que qual¬ 
quer um destes dois eventos ocorra: 

1. Alcançar a frente da cadeia de LRU e ser expulso. 

2. Uma chamada de sistema SYNC for executada. 

SYNC não varre a cadeia de LRU, mas em vez disso percorre 
a matriz de buffers no cache. Mesmo se um buffer ainda 


não foi liberado, se foi modificado, SYNC irá localizá-lo e 
assegurará que a cópia em disco seja atualizada. 

Há uma exceção, contudo. Um superbloco modificado 
é gravado em disco imediatamente. Em uma versão mais 
antiga do MINTX, um superbloco era modificado quando 
um sistema de arquivos era montado, e o propósito da gra¬ 
vação imediata era reduzir a chance de corromper o siste¬ 
ma de arquivos em caso de uma queda. Os superblocos não 
são modificados agora, então, o código para gravá-los ime¬ 
diatamente é um anacronismo. Na configuração-padrão, 
nenhum outro bloco é gravado imediatamente. Entretan¬ 
to, modificando-se a definição padrão de ROBUST no ar¬ 
quivo de configuração de sistema, include/minix/config. h, 
o sistema de arquivos pode ser compilado para marcar blo¬ 
cos de nós-i, de diretórios, de mapa de bits ou indiretos de 
tal modo que eles sejam gravados imediatamente na libe¬ 
ração. Isso com objetivo de fazer o sistema de arquivos mais 
robusto; o preço a ser pago é a operação mais lenta. Se isso 
será efetivo, não é claro. Uma falta de energia que ocorra 
quando todos os blocos ainda não foram gravados causará 
uma dor de cabeça se um nó-i ou um bloco de dados for 
perdido. 

Note que o sinalizador de cabeçalho indicando que um 
bloco foi modificado é configurado pelo procedimento den¬ 
tro do sistema de arquivos que solicitou e utilizou o bloco. 
Os procedimentos get_block e put_block estão preocupa¬ 
dos apenas com manipuladores das listas encadeadas. Eles 
não têm nenhuma idéia de qual procedimento do sistema 
de arquivos quer qual bloco ou por quê. 

5.6.6 Diretórios e Caminhos 

Outro subsistema importante dentro do sistema de ar¬ 
quivos é o gerenciamento de diretórios e os nomes de ca¬ 
minho. Muitas chamadas de sistema, como open, têm um 
nome de arquivo como parâmetro. O que é realmente ne¬ 
cessário é o nó-i para esse arquivo, então, cabe ao sistema 
de arquivos localizar o arquivo na árvore de diretórios e 
obter seu nó-i. 

Um diretório MINIX consiste em um arquivo contendo 
entradas de 16 bytes. Os primeiros 2 bytes formam um nú¬ 
mero de nó-i de 16 bits e os 14 bytes restantes são o nome 
do arquivo. Essa é a mesma entrada de diretório tradicio¬ 
nal do UNIX que vimos na ilustração da Figura 5-13- Para 
procurar o caminho / usr/ast/mbox , o sistema primeiro 
localiza usr no diretório-raiz, então, localiza as/ em usre, 
por fim, localiza mbox em /usr/ast. A pesquisa real segue 
um componente do caminho por vez como ilustrado na 
Figura 5-14. 

A única complicação é o que acontece quando um sis¬ 
tema de arquivos montado é encontrado. A configuração 
normal para o MINIX e para muitos outros sistemas tipo 
UNIX é ter um pequeno sistema de arquivos-raiz contendo 
os arquivos necessários para iniciar o sistema e fazer a ma¬ 
nutenção básica de sistema, e ter a maioria dos arquivos, 
incluindo diretórios dos usuários, em um dispositivo sepa¬ 
rado montado em /usr. Esse é um bom momento para ver 
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como a montagem é feita. Quando o usuário digita o co¬ 
mando 

mount /dev/hd2c /usr 

no terminal, o sistema de arquivos contido na partição 2 
do disco rígido é montado sobre /usr no sistema de arqui¬ 
vos raiz. Os sistemas de arquivos antes e depois da monta¬ 
gem são mostrados na Figura 5-32. 

A chave para todo o negócio da montagem é um sinali¬ 
zador configurado na cópia em memória do nó-i de/usr 
após uma montagem bem-sucedida. Esse sinalizador in¬ 
dica que o nó-i foi montado. A chamada MOUNT também 
carrega o superbloco do sistema de arquivos recentemente 
montado na tabela super _block e configura dois ponteiros 
nela. Além disso, ele coloca o nó-i raiz do sistema de arqui¬ 
vos montado na tabela inode. 

Na Figura 5-29, vemos que os superblocos na memória 
contêm dois campos relacionados com sistemas de arqui¬ 
vos montados. 0 primeiro desses, o nó-i-do-sistema-de- 
arquivo-montado, é configurado para apontar para o nó- 
i raiz do sistema de arquivos recentemente montado. O se¬ 
gundo, nó-i-montado, é configurado para apontar para o 
nó-i onde ocorreu a montagem, nesse caso o nó-i de/usr. 
Esses dois ponteiros servem para conectar o sistema de ar¬ 
quivos montado à raiz e representam a “cola” que une o 
sistema de arquivos montado à raiz [mostrado como os 
pontos na Figura 5-32 (c) ]. Essa cola é o que faz os siste¬ 
mas de arquivos montados funcionarem. 

Quando um caminho como /usr/ast/f2 está sendo pes¬ 
quisado, o sistema de arquivos olha em um sinalizador no 
nó-i de íusr e sabe que deve continuar a pesquisar no nó-i 


raiz do sistema de arquivos montado em /usr. A pergunta 
é: “Como localiza esse nó-i raiz”? 

A resposta é simples e direta. O sistema pesquisa todos 
os superblocos na memória até encontrar aquele cujo cam¬ 
po nó-i montado aponta para /usr. Esse deve ser o super¬ 
bloco para o sistema de arquivos montado em /usr. Uma 
vez que ele tem o superbloco, é fácil seguir o outro pontei¬ 
ro para localizar o nó-i raiz para o sistema de arquivos 
montado. Agora, o sistema de arquivos pode continuar a 
pesquisar. Nesse exemplo, ele procura ast no diretório-raiz 
da partição do disco rígido 2. 

5-6.7 Descritores de Arquivos 

Uma vez que um arquivo foi aberto, um descritor de 
arquivo é retornado para o processo de usuário para utili¬ 
zação em subseqüentes chamadas read e write. Nesta se¬ 
ção, veremos como descritores de arquivos são gerenciados 
dentro do sistema de arquivos. 

Como o kernel e com o gerenciador de memória, o sis¬ 
tema de arquivos mantém parte da tabela de processos den¬ 
tro de seu espaço de endereços. Três dos seus campos são de 
interesse particular. Os primeiros dois são ponteiros para os 
nós-i para o diretório-raiz e para o diretório de trabalho. As 
pesquisas de caminho, como a da Figura 5-14, sempre co¬ 
meçam em um ou em outro, dependendo de o caminho ser 
absoluto ou relativo. Esses ponteiros são alterados pelas cha¬ 
madas de sistema CHROOT e CHDIR para apontar para a nova 
raiz ou para novo diretório de trabalho respectivamente. 

O terceiro campo interessante na tabela de processos é 
uma matriz indexada pelo número do descritor de arqui- 


Sistema de 
arquivos raiz 

/ 



(a) 


Sistema de 

arquivos a ser montado 

/ 



(b) 


Depois da 
montagem 

/ 



/usr/bal 



Figura 5-32 (a) Sistema de arquivos raiz. (b) Um sistema de arquivos não-montado. (c) 0 resultado da montagem do sistema de 

arquivos de (b) em/usr. 
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vo. Ela é utilizada para localizar o arquivo adequado quan¬ 
do um descritor de arquivo é apresentado. À primeira vista, 
talvez pareçam suficientes ter a k-ésima entrada nessa 
matriz apontando simplesmente para o nó-i do arquivo 
pertencente ao descritor de arquivo k. Afinal de contas, o 
nó-i é buscado na memória quando o arquivo está aberto e 
é mantido aí até que seja fechado, assim ele fica seguro de 
estar disponível. 

Infelizmente, esse plano simples falha porque os arqui¬ 
vos podem ser compartilhados de maneiras sutis no minix 
(assim como no UNIX). O problema surge porque associa¬ 
do com cada arquivo está um número de 32 bits que indica 
o próximo byte a ser lido ou gravado. É esse número, 
chamado posição do arquivo, que é alterado pelo cha¬ 
mada de sistema LSKEK. O problema pode ser facilmente 
declarado: “Onde o ponteiro de arquivo deve estar armaze¬ 
nado? ” 

A primeira possibilidade é colocá-lo no nó-i. Infeliz- 
mente, se dois ou mais processos tiverem aberto ao mesmo 
tempo o mesmo arquivo, todos eles deverão ter os próprios 
ponteiros de arquivo, uma vez que seria péssimo que uma 
LSEKK de um processo afetasse a próxima leitura de um 
processo diferente. A conclusão: a posição do arquivo não 
pode entrar no nó-i. 

Que tal colocá-lo na tabela de processos? Por que não 
ter uma segunda matriz, paralela à matriz de descritores 
de arquivos, dando a posição atual de cada arquivo? Essa 
idéia também não funciona, mas a razão é mais sutil. Ba¬ 
sicamente, o problema vem da semântica da chamada de 
sistema FORK. Quando um processo bifurca, exige-se que 
pai e filho compartilhem um único ponteiro que dá a posi¬ 
ção atual de cada arquivo aberto. 

Para entender melhor o problema, considere o caso de 
um script do shell cuja saída foi redirecionada para um 
arquivo. Quando o shell bifurca o primeiro programa, sua 
posição de arquivo para saída-padrão é 0. Essa posição, 
então, é herdada pelo filho, que grava, digamos, 1K de sa¬ 
ída. Quando o filho termina, aposição de arquivo compar¬ 
tilhada agora deve ser de 1K. 


Agora o shell lê algo mais do script de shell e cria outro 
filho. É essencial que a segundo filho herde uma posição 
de arquivo em um 1K do shell, de modo que ele começará a 
gravar no lugar que o primeiro programa parou. Se o shell 
não compartilhou a posição de arquivo com seus filhos, o 
segundo programa sobrescreveria a saída do primeiro, em 
vez de anexar a ela. 

Como resultado, não é possível colocar a posição de 
arquivo na tabela de processos. Ela realmente deve ser com¬ 
partilhada. A solução utilizada no minix é introduzir uma 
nova tabela compartilhada, filp, que contém todas as posi¬ 
ções de arquivo. Sua utilização é ilustrada na Figura 5-33. 
Por ter a posição de arquivo verdadeiramente comparti¬ 
lhada, a semântica de FORK pode ser implementada corre¬ 
tamente, e Scripts de shell funcionam adequadamente. 

Embora a única coisa que a tabela filp realmente deve 
conter é a posição de arquivo compartilhado, é convenien¬ 
te colocar o ponteiro de nó-i aí, também. Assim, tudo que a 
matriz de descritores de arquivos na tabela de processos 
contém é um ponteiro para uma entrada filp. A entrada 
filp também contém o modo do arquivo (bits de permis¬ 
são), alguns sinalizadores que indicam se o arquivo foi 
aberto em um modo especial e uma contagem do número 
de processos que o estão utilizando; então, o sistema de 
arquivos pode dizer quando terminou o último processo 
que está utilizando a entrada, a fim de reivindicá-la. 

5-6.8 Bloqueio de Arquivos 

Há ainda outro aspecto de gerenciamento do sistema 
de arquivos que requer uma tabela especial. Isso é o blo¬ 
queio de arquivos. O MINIX suporta o mecanismo de comu¬ 
nicação interprocesso do POSIX de bloqueio de arquivo 
consultivo. Este último permite que qualquer parte, ou 
múltiplas partes, de um arquivo sejam marcadas como blo¬ 
queadas. O sistema operacional não impõe bloquear, mas 
espera-se que os processos sejam mais comportados e pes¬ 
quisem bloqueios em um arquivo antes de fazer qualquer 
coisa que geraria conflitos com outro processo. 


Tabela de 

Tabela filp nós-i 



Figura 5-33 Como posições de arquivo são compartilhadas entre um pai e um filho. 
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As razões para oferecer uma tabela separada para blo¬ 
queios são semelhantes às justificativas para a tabela////), 
discutida na seção anterior. Um único processo pode ter 
mais de um bloqueio ativo, e diferentes partes de um ar¬ 
quivo podem ser bloqueadas por mais de um processo (em¬ 
bora, naturalmente, os bloqueios não possam sobrepor-se), 
assim nem a tabela de processos nem a tabela/// são um 
bom lugar para registrar bloqueios. Uma vez que um ar¬ 
quivo pode ter mais de um bloqueio colocado sobre ele, o 
nó-i também não é um bom lugar. 

0 MiNix utiliza outra tabela, a tabela filejock, para 
registrar todos os bloqueios. Cada entrada nessa tabela tem 
espaço para um tipo de bloqueio, indicando se o arquivo é 
bloqueado para leitura ou para escrita, o ID do processo 
que está fazendo o bloqueio, um ponteiro para o nó-i do 
arquivo bloqueado e os deslocamentos do primeiro e do 
último bytes da região bloqueada. 

5.6.9 Canalizações e Arquivos Especiais 

As canalizações ipipes) e arquivos especiais diferem de 
arquivos comuns de uma maneira importante. Quando um 
processo tenta ler ou gravar em um arquivo de disco, é cer¬ 
to que a operação irá completar-se dentro de algumas cen¬ 
tenas de milissegundos no máximo. No pior caso, dois ou 
três acessos de disco talvez sejam necessários, não mais. Ao 
ler de uma canalização, a situação é diferente: se a canali¬ 
zação estiver vazia, o leitor precisará esperar até que al¬ 
gum outro processo coloque dados na canalização, o que 
talvez leve horas. De maneira semelhante, ao ler de um 
terminal, um processo terá de esperar até que alguém digi¬ 
te algo. 

Como conseqüência, a regra normal do sistema de ar¬ 
quivos de tratar uma solicitação até que ela termine o tra¬ 
balho não funciona. É necessário suspender essas solicita¬ 
ções e reiniciá-las mais tarde. Quando um processo tenta 
ler ou gravar de uma canalização, o sistema de arquivos 
pode verificar o estado da canalização imediatamente para 
ver se a operação pode ser completada. Se puder, ela é com¬ 
pletada, mas, se não puder, o sistema de arquivos registra os 
parâmetros da chamada de sistema na tabela de processos, 
assim ele pode reiniciar o processo quando a hora chegar. 

Note que o sistema de arquivos não precisa realizar 
qualquer ação para ter o chamador suspenso. Tudo que ele 
precisa fazer é deixar de enviar uma resposta, deixando o 
chamador esperar a resposta bloqueado. Assim, depois de 
suspender um processo, o sistema de arquivos volta ao seu 
laço principal, esperando a próxima chamada de sistema. 
Logo que outro processo modifica o estado da canalização, 
de modo que o processo suspenso possa continuar, o siste¬ 
ma de arquivos ativa um sinalizador para que da próxima 
vez que passar pelo laço principal ele extraia os parâme¬ 
tros do processo suspenso da tabela de processos e execute 
a chamada. 

A situação com terminais e com outros arquivos espe¬ 
ciais de caractere é ligeiramente diferente. 0 nó-i para cada 
arquivo especial contém dois números, o dispositivo prin¬ 


cipal e o dispositivo secundário. 0 número de dispositivo 
principal indica a classe do dispositivo (p. ex., disco de RAM, 
disquete, disco rígido, terminal). Ele é utilizado como um 
índice em uma tabela do sistema de arquivos que o ma- 
peia para o número da tarefa correspondente (i. e., driver 
de E/S). De fato, o dispositivo principal determina qual 
driver de E/S chamar. 0 número do dispositivo secundário 
é passado para o driver como um parâmetro. Ele especifi¬ 
ca qual dispositivo deve ser utilizado, por exemplo, termi¬ 
nal 2 ou unidade 1. 

Em alguns casos, principalmente dispositivos de termi¬ 
nal, o número de dispositivo secundário codifica algumas 
informações sobre uma categoria de dispositivos tratada 
por uma tarefa. Por exemplo, o console primário do MINIX, 
/dev/console, é o dispositivo 4, 0 (primário, secundário). 
Consoles virtuais são tratados pela mesma parte do softwa¬ 
re de driver. Estes últimos são os dispositivos /dev/ttycl 
(4,1), /dev/ ttyc2 (4, 2) e assim por diante. Terminais de 
linha serial necessitam de software de baixo nível diferen¬ 
te, e a esses dispositivos, /dev/ttyOO e/dev/tty01, são atri¬ 
buídos os números de dispositivo 4,16 e 4,17. De maneira 
semelhante, terminais de rede utilizam drivers Atpseudo- 
terminal e estes últimos também necessitam de software 
de baixo nível diferente. No MiNix, a esses dispositivos, ttypO, 
ttypl etc., são atribuídos números de dispositivo como 4, 
128 e 4, 129. Cada um desses pseudodispositivos tem um 
dispositivo associado, ptypO,ptypl. etc. Os pares primário, 
secundário de número de dispositivo para esses são 4,192, 
4,193 e assim por diante. Esses números são escolhidos para 
tornar fácil para a tarefa de driver chamar as funções de 
baixo nível requeridas para cada grupo de dispositivos. Não 
há nenhuma expectativa de que qualquer pessoa irá equi¬ 
par um sistema minix com 192 ou com mais terminais. 

Quando um processo lê de um arquivo especial, 0 siste¬ 
ma de arquivos extrai os números de dispositivo primário e 
secundário do nó-i do arquivo e utiliza 0 número de dispo¬ 
sitivo principal como um índice em uma tabela de sistema 
de arquivos a fim de mapeá-lo para 0 número de tarefa 
correspondente. Uma vez que tenha 0 número de tarefa, 0 
sistema de arquivos envia à tarefa uma mensagem, inclu¬ 
indo como parâmetros 0 dispositivo secundário, a opera¬ 
ção a ser executada, 0 número de processo e 0 endereço de 
buffer do chamador e 0 número de bytes a serem transferi¬ 
dos. 0 formato é 0 mesmo que da Figura 3-15, exceto que 
POSniON não é utilizado. 

Se 0 driver for capaz de executar 0 trabalho imediata¬ 
mente (p. ex., uma linha de entrada já foi digitada no ter¬ 
minal) , ele copia os dados dos próprios buffers internos para 
0 usuário e envia ao sistema de arquivos uma mensagem 
de resposta, dizendo que 0 trabalho está feito. 0 sistema de 
arquivos, então, envia uma mensagem de resposta para 0 
usuário, e a chamada termina. Note que 0 driver não co¬ 
pia os dados para 0 sistema de arquivos. Os dados proveni¬ 
entes dos dispositivos de blocos vão pelo cache de blocos, 
mas dados de arquivos especiais de caractere não. 

Por outro lado, se 0 driver não for capaz de executar 0 
trabalho, ele registra os parâmetros da mensagem em suas 
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tabelas internas e imediatamente envia uma resposta para 
o sistema de arquivos, dizendo que a chamada não pôde 
ser completada. Nesse ponto, o sistema de arquivos está na 
mesma situação que estaria se tivesse descoberto que al- 
gue'm está tentando ler de uma canalização vazia. Ele re¬ 
gistra o fato de que o processo está suspenso e espera a pró¬ 
xima mensagem. 

Quando o driver adquiriu dados suficientes para com¬ 
pletar a chamada, transfere-os ao buffer do usuário ainda 
bloqueado e, então, envia ao sistema de arquivos uma men¬ 
sagem que informa o que fez. Hido o que o sistema de ar¬ 
quivos precisa fazer é enviar uma mensagem de resposta 
ao usuário para desbloqueá-lo e informar o número de bytes 
transferidos. 

5.6.10 Um Exemplo: a Chamada de 
Sistema READ 

Como veremos brevemente, a maior parte do código do 
sistema de arquivos é dedicada para dar conta de chama¬ 
das de sistema. Portanto, é apropriado concluirmos essa 
visão geral com um breve esboço de como a chamada mais 
importante, READ, funciona. 

Quando um programa de usuário executa a declara¬ 
ção 

n = read(fd, buffer, nbytes); 

para ler um arquivo comum, o procedimento de biblioteca 
read é chamado com três parâmetros. Ele constrói uma 
mensagem que contém tais parâmetros, junto com o códi¬ 
go para READ como o tipo de mensagem, envia a mensa¬ 
gem para o sistema de arquivos e fica suspenso aguardan¬ 
do a resposta. Quando a mensagem chega, o sistema de 
arquivos utiliza o tipo de mensagem como um índice em 
suas tabelas para chamar o procedimento que trata a lei¬ 
tura. 

Esse procedimento extrai o descritor de arquivo da men¬ 
sagem e utiliza-o para localizar a entrada filp ; então, o nó- 
i para o arquivo a ser lido (veja a Figura 5-33). A solicita¬ 
ção, então, é dividida em pedaços de tal modo que cada 
pedaço ajusta-se dentro de um bloco. Por exemplo, se a 
posição do arquivo atual for 600 e 1K bytes tiverem sidos 
solicitados, a solicitação será dividida em duas partes, de 
600 até 1023 e de 1024 até 1623 (supondo blocos de 1K). 

Para cada um desses pedaços, por sua vez, é verificado 
se o bloco relevante está no cache. Se o bloco não estiver 
presente, o sistema de arquivos seleciona o buffer menos 
recentemente utilizado que não esteja em uso e reivindica- 
o, enviando uma mensagem à tarefa de disco para regra- 
vá-lo se ele estiver sujo. Então, é solicitado à tarefa de disco 
que busque o bloco a ser lido. 

Uma vez que o bloco está no cache, o sistema de arqui¬ 
vos envia uma mensagem à tarefa de sistema, pedindo-lhe 
para copiar os dados para o lugar apropriado no buffer do 
usuário (i. e., bytes 600 até 1023 para o início do buffer e 
bytes 1024 até 1623 para o deslocamento 424 dentro do 
buffer). Depois que a cópia foi feita, o sistema de arquivos 


envia uma mensagem de resposta para o usuário especifi¬ 
cando quantos bytes foram copiados. 

Quando a resposta volta para o usuário, a função de 
biblioteca read extrai o código de resposta e retorna-o como 
o valor da função para o chamador 

Há um passo extra que não é realmente parte da cha¬ 
mada read em si. Depois que o sistema de arquivos com¬ 
pleta uma leitura e envia uma resposta, ele, então, inicia 
uma leitura do próximo bloco, desde que a leitura seja de 
um dispositivo de bloco e outras condições particulares se¬ 
jam satisfeitas. Uma vez que leituras seqüenciais de arqui¬ 
vo são comuns, é razoável esperar que o próximo bloco em 
um arquivo seja solicitado na próxima solicitação de lei¬ 
tura e isso torna possível que o bloco desejado já esteja no 
cache quando for necessário. 

5.7 IMPLEMENTAÇÃO DO SISTEMA DE 
ARQUIVOS DO MINIX 

O sistema de arquivos do MINIX é relativamente grande 
(mais de 100 páginas em C), mas bem simples e direto. As 
solicitações para executar chamadas de sistema chegam, 
são executadas e respostas são enviadas. Nas seções a se¬ 
guir, nós o estudaremos um arquivo por vez, indicando os 
destaques. O próprio código contém muitos comentários 
que ajudam o leitor. 

Ao examinar o código de outras partes do MINIX geral¬ 
mente olhamos primeiro o laço principal de um processo 
e, então, olhamos as rotinas que tratam os diferentes tipos 
de mensagem. Organizaremos nossa abordagem para o sis¬ 
tema de arquivos de maneira diferente. Primeiro, passare¬ 
mos pelos subsistemas importantes (gerenciamento de ca¬ 
che, gerenciamento de nós-i, etc.). Então, veremos o laço 
principal e as chamadas de sistema que operam sobre ar¬ 
quivos. Em seguida, veremos chamadas de sistema que 
operam sobre diretórios. Por fim, discutiremos as chama¬ 
das de sistema restantes que não entram em nenhuma ca¬ 
tegoria. 

5.7.1 Arquivos Cabeçalho e Estruturas 
de Dados Globais 

Como o kernel e o gerenciador de memória, várias es¬ 
truturas de dados e tabelas utilizadas no sistema de arqui¬ 
vos são definidas em arquivos de cabeçalho. Algumas des¬ 
sas estruturas de dados são colocadas em arquivos de cabe¬ 
çalho de sistema em incliide/ e seus subdiretórios. Por 
exemplo, include/sys/stat.h define o formato por meio do 
qual chamadas de sistema podem oferecer as informações 
de nó-i para outros programas, e a estrutura de uma entra¬ 
da de diretório é definida em include/sys/dir.h. Ambos ar¬ 
quivos são exigidos pelo posix. 0 sistema de arquivos é afe¬ 
tado por diversas definições contidas no arquivo global de 
configuração include/minix/config.h, como a macro RO- 
BUST que define se estruturas de dados importantes do sis¬ 
tema de arquivos sempre serão gravadas imediatamente 
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no disco e NR_BUFS e NR_BUF_HASH, que controlam o 
tamanho do cache de blocos. 

Cabeçalhos do Sistema de Arquivos 

Os arquivos de cabeçalho do próprio sistema de arqui¬ 
vos estão no diretório de fontes do sistema de arquivos src/ 
fs/. Muitos nomes de arquivo serão familiares a partir do 
estudo de outras partes do sistema minix. 0 arquivo de ca¬ 
beçalho-mestre do sistema de arquivos,/?./; (linha 19400), 
é muito semelhante asrc/kemel/kemel.h esrc/mm/mm.h. 

Ele inclui outros arquivos de cabeçalho necessários por to¬ 
dos os arquivos-fonte de C no sistema de arquivos. Como 
nas outras partes do minix, o cabeçalho-mestre do sistema 
de arquivos inclui const.h , type.h.proto.h eglo.h próprios 
do sistema de arquivos. Veremos estes últimos a seguir. 

Const.h (Linha 19500) define algumas constantes como 
tamanhos de tabela e sinalizadores, que são utilizadas por 
todo o sistema de arquivos. O MINIX já tem uma história. 
Uma versão anterior teve um sistema de arquivos diferen¬ 
te, e para usuários que queiram acessar arquivos gravados 
pela versão anterior, é oferecido suporte para ambos, o sis¬ 
tema de arquivos VI antigo e o V2 atual. O superbloco de 
um sistema de arquivos contém um número mágico para 
que o sistema operacional possa identificar o tipo; as cons¬ 
tantes SUPER_MAGIC e SUPER_V2 definem esses núme¬ 
ros. O suporte de versões antigas não é algo que se possa ler 
em textos teóricos, mas é sempre um interesse para o im- 
plementorador de uma nova versão de qualquer software. 
Deve-se decidir quanto esforço será dedicado para tornar a 
vida mais fácil para o usuário da versão antiga. Veremos 
vários lugares no sistema de arquivos onde o suporte para 
a versão antiga é uma questão importante. 

Type.h (Linha 19600) define as estruturas de nó-i VI 
(antigas) e V2 (novas) como são colocadas no disco. O nó- 
i V2 é duas vezes maior que 0 antigo, que foi projetado 
para ser compacto em sistemas sem disco rígido e disque¬ 
tes de 360KB. A nova versão oferece espaço para os três cam¬ 
pos de tempo que os sistemas UNIX oferecem. No nó-i VI, 
havia somente um campo de tempo, mas um STAT ou fstat 
“fingia” e retornava uma estruturaste/ contendo todos os 
três campos. Aqui há uma pequena dificuldade em ofere¬ 
cer suporte para as duas versões do sistema de arquivos. 
Isso é indicado pelo comentário na linha 19616 .0 softwa¬ 
re MINIX mais antigo espera que 0 tipo gidj tenha um ta¬ 
manho de 8 bits, então, d2_gid deve ser declarado como 
tipo ul6_t. 

Proto.h (linha 19700) oferece protótipos de função em 
formas aceitáveis tanto para compiladores antigos, K&R 
como para compiladores padrão ANSI C mais recentes. É 
um arquivo longo, mas não de grande interesse. Entretan¬ 
to, há um ponto a notar: como há tantas chamadas de sis¬ 
tema diferentes tratadas pelo sistema de arquivos, e por 
causa da maneira como 0 sistema de arquivos é organiza¬ 
do, as várias funções do_.xxx estão dispersas por vários ar¬ 
quivos. Proto.h é organizado por arquivo e é uma maneira 
útil de localizar 0 arquivo a consultar quando você quiser 


ver 0 código que trata uma chamada de sistema em parti¬ 
cular. 

Por fim, glo.h (linha 19900) define as variáveis glo¬ 
bais. Os buffers de mensagem para as mensagens que che¬ 
gam e para as mensagens de resposta também estão aqui. 

O truque agora familiar com a macro EXTERNé utilizado, 
assim tais variáveis podem ser acessadas por todas as par¬ 
tes do sistema de arquivos. Como nas outras partes do MI- 
NIX 0 espaço de armazenamento será reservado quando 
table.c for compilado. 

A parte do sistema de arquivos na tabela de processos 
está contida em fproc.h (linha 20000). A matriz fproc é 
declarada com a macro EXTERN. Ela armazena a máscara 
de modos, os ponteiros para os nós-i dos diretórios raiz e de 
trabalho atuais, a matriz de descritores de arquivo, uid, 
gid e número de terminal para cada processo. O id do pro¬ 
cesso e 0 id de grupo do processo também estão localizados 
aqui. Esses são duplicados em partes da tabela de processos 
localizada no kernel e no gerenciador de memória. 

Vários campos são utilizados para armazenar os parâ¬ 
metros das chamadas de sistema que podem ser suspensas 
no meio do caminho, como leituras de uma canalização 
vazia. Os campos fp_suspmded tfp_revived requerem 
apenas bits simples, mas quase todos os compiladores ge¬ 
ram código melhor para caracteres do que para campos de 
bit. Também há um campo para os bits FDJ2LOEXEC in¬ 
dicados pelo padrão POSIX. Esses são utilizados para indi¬ 
car que um arquivo deve ser fechado quando uma chama¬ 
da exec é feita. 

Agora chegamos aos arquivos que definem outras tabe¬ 
las mantidas pelo sistema de arquivos. O primeiro, buf.h 
(linha 20100), define 0 cache de blocos. As estruturas aqui 
são todas declaradas com EXTERN. A matriz buf armaze¬ 
na todos os buffers, cada um dos quais contém uma parte 
de dados, b, e um cabeçalho cheio de ponteiros, de sinali¬ 
zadores e de contadores. A parte de dados é declarada como 
uma união de cinco tipos (linha 20117) porque, às vezes, é 
conveniente referenciar 0 bloco como uma matriz de ca¬ 
racteres, outras vezes, como um diretório, etc. 

A maneira adequada de referenciar a parte de dados do 
buffer 3 como uma matriz de caracteres é buj[5].b.b_ 
_dãta porque buf[3]-b referencia a união como um todo, 
a partir da qual 0 campo b_ _jiata é selecionado. Embora 
essa sintaxe seja correta, ela é enfadonha; então, na linha 
20142 definimos uma macro b_ data que nos permite es¬ 
crever buj\l\.b_ data no lugar. Note que b_ _data (0 
campo da união) contém dois sublinhados, ao passo que 
b_ data (a macro) contém somente um, para distingui- 
los. As macros para outras maneiras de acessar 0 bloco são 
definidas nas linhas 20143 até 20148. 

A tabela de hash de buffers, buf_hash, é definida na 
linha 20150. Cada entrada aponta para uma lista de bu¬ 
ffers. Originalmente todas as listas estão vazias. As macros 
no fim de buf.h (linhas 20160 a 20166 ) definem diferentes 
tipos de blocos. Quando um bloco é retornado para 0 cache 
de buffers depois de utilizado, um desses valores é forneci¬ 
do para dizer ao gerenciador de cache se é para colocar 0 
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bloco na frente ou no fundo da lista de LRU e se é para 
gravar em disco imediatamente ou não. O bit WRITE 
JMMED sinaliza que um bloco deve ser regravado no dis¬ 
co imediatamente se for alterado. O superbloco é a única 
estrutura incondicionalmente marcada com isso. E quan¬ 
to à outra estrutura marcada com MATBE_WR!TEJMMED"! 
Essa é definida em inclu.de/ minix/config.h para ser igual 
a WRITEJMMED se ROBUSTfor verdadeiro ou 0 caso con¬ 
trário. Na configuração-padrão do minix, ROBUST é defi¬ 
nido como 0 e esses blocos serão gravados quando blocos 
de dados forem gravados. 

Por fim, na última linha (linha 20168) HASH_MASKé 
definida com base no valor deNR_BUF_HASH configura¬ 
do em include/ minix/config.h. HASHJMASKé “associada 
por meio da operação AND” com um número de bloco para 
determinar qual entrada em buf_hash utilizar como o pon¬ 
to de partida para uma pesquisa por um buffer de bloco. 

O próximo arquivo, dev.h (linha 20200) define a tabe¬ 
la dmap. A tabela em si é declarada em table. c com valo¬ 
res iniciais, assim tal versão não pode ser incluída em vári¬ 
os arquivos. Essa é a razão por que dev. h é necessário. Dmap 
é declarado aqui com extern, em vez de EXTERN. A tabela 
oferece o mapeamento entre o número de dispositivo prin¬ 
cipal e a tarefa correspondente. 

File.h (linha 20300) contém a tabela intermediária/z'/ 
(declarada como EXTERN), utilizada para armazenar a 
posição de arquivo atual e o ponteiro de nó-i (veja a Figu¬ 
ra 5-33)- Também diz se o arquivo foi aberto para leitura, 
para gravação ou para ambos e quantos descritores de ar¬ 
quivo atualmente estão apontando para a entrada. 

A tabela de bloqueio de arquivo filejock (declarada 
como EXTERN), está em lock. b (linha 20400). O tamanho 
da matriz é determinado por NR_LOCKS, que é definido 
como 8 em const.h. Esse número deve ser aumentado se 
for desejado implementar um banco de dados multiusuá- 
rio em um sistema MINIX. 

Em inode.h (linha 20500), a tabela de nós-i inode é 
declarada (utilizando EXTERN). Ela armazena os nós-i que 
estão atualmente em uso. Como dissemos anteriormente, 
quando um arquivo está aberto seu nó-i é carregado na 
memória e mantido aí até que o arquivo seja fechado. A 
definição de estrutura inode fornece as informações que 
são mantidas na memória, mas não gravadas no nó-i em 
disco. Note que há apenas uma versão e que nada é especí¬ 
fico de versão aqui. Quando o nó-i é lido do disco, as dife¬ 
renças entre os sistemas de arquivos VI e V2 são tratadas. O 
restante do sistema de arquivos não necessita saber sobre o 
formato do sistema de arquivos no disco, pelo menos até 
chegar a hora de gravar de volta as informações modificadas. 

A maioria dos campos deve ser auto-explicativa nesse 
ponto. Entretanto, i_seek merece algum comentário. Foi 
mencionado anteriormente que, como otimização, quan¬ 
do o sistema de arquivos nota que um arquivo está sendo 
lido seqüencialmente, ele tenta ler blocos no cache mesmo 
antes de eles serem pedidos. Para arquivos acessados alea¬ 
toriamente, não há nenhuma leitura antecipada. Quando 


uma chamada I.SEEK é feita, o campo i_seek é ligado para 
inibir o buffer de leitura antecipada. 

O arquivo param.b (linha 20600 ) é análogo ao arqui¬ 
vo de mesmo nome no gerenciador de memória. Ele define 
nomes para campos de mensagem contendo parâmetros, 
assim o código pode referenciar, por exemplo, buffer, em 
vez Aem.ml_pl, o que seleciona um dos campos do bu¬ 
ffer da mensagem m. 

Em super, b (linha 20700) temos a declaração da tabe¬ 
la de superbloco. Quando o sistema é inicializado, o super¬ 
bloco para o dispositivo-raiz é carregado aqui. Quando sis¬ 
temas de arquivos são montados, seus superblocos entram 
aqui também. Como com outras tabelas, super _block é 
declarada como EXTERN. 

Alocação de Armazenamento do Sistema 
de Arquivos 

O último arquivo que discutiremos nesta seção não é 
um cabeçalho. Entretanto, como fizemos ao discutir o ge¬ 
renciador de memória, parece apropriado discutir table. c 
imediatamente depois de revisar os arquivos de cabeçalho, 
uma vez que todos são incluídos quando table. cé compi¬ 
lado. Muitas das estruturas de dados que mencionamos — 
o cache de bloco, a tabela filp e assim por diante — são 
definidas com a macro EXTERN, assim como também são 
as variáveis globais do sistema de arquivos e a parte do sis¬ 
tema de arquivos da tabela de processos. Da mesma ma¬ 
neira como vimos em outras partes do sistema MINIX, o es¬ 
paço de armazenamento é realmente reservado quando 
table. c é compilado. Esse arquivo também contém duas 
importantes matrizes inicializadas. Call_vector contém a 
matriz de ponteiros utilizada no laço principal para deter¬ 
minar qual procedimento trata qual número de chamada 
de sistema. Vimos uma tabela semelhante dentro do ge¬ 
renciador de memória. 

Uma coisa nova, entretanto, é a tabela dmap na linha 
20914. Essa tabela tem uma linha para cada dispositivo 
principal, iniciando em zero. Quando um dispositivo é aber¬ 
to, lido, fechado ou gravado, é essa tabela que oferece 0 
nome do procedimento a chamar para tratar a operação. 
Todos esses procedimentos são localizados no espaço de 
endereço do sistema de arquivos. Muitos desses procedimen¬ 
tos não fazem nada, mas alguns chamam uma tarefa para 
de fato solicitar E/S. O número de tarefa correspondente 
a cada dispositivo principal também é oferecido pela tabe¬ 
la. 

Sempre que um novo dispositivo principal é adiciona¬ 
do ao MINIX, uma linha deve ser adicionada a essa tabela 
informando que a ação, se alguma, deve ser tomada quan¬ 
do 0 dispositivo é aberto, fechado, lido ou gravado. Como 
um exemplo simples, se uma unidade de fita é adicionada 
ao MINIX, quando seu arquivo especial é aberto, 0 procedi¬ 
mento na tabela poderia verificar se a unidade de fita já 
está em utilização. Para poupar os usuários do trabalho de 
modificar essa tabela ao fazer a reconfiguração, uma ma- 
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cro, DT, é definida para automatizar o processo (linha 
20900). 

Há uma linha na tabela para cada possível dispositivo 
principal e cada linha é escrita com a macro. Dispositivos 
solicitados têm um 1 como 0 valor do argumento eriable 
para a macro. Algumas entradas não são utilizadas, seja 
porque um driver planejado ainda não está pronto, seja 
porque um driver antigo foi removido. Essas entradas são 
definidas com um valor de 0 para enable. As entradas para 
dispositivos que podem ser configurados em include/mi- 
nix/config.h utilizam a macro que ativa 0 dispositivo, por 
exemplo, ENABLE_WINI na linha 20920. 

5.7.2 Gerenciamento de Tabelas 

Associado a cada uma das tabelas principais — blocos, 
nós-i, superblocos, etc. — está um arquivo que contém 
procedimentos que gerenciam a tabela. Esses procedimen¬ 
tos são intensamente utilizados pelo restante do sistema de 
arquivos e formam a interface principal entre as tabelas e 
0 sistema de arquivos. Por essa razão, é apropriado come¬ 
çar nosso estudo sobre 0 código do sistema de arquivos a 
partir desses procedimentos. 

Gerenciamento de Blocos 

O cache de blocos é gerenciado pelos procedimentos no 
arquivo cache. c. Esse arquivo contém os nove procedimen¬ 
tos listados na Figura 5-34. O primeiro, getjjlock (linha 
21027), é a maneira-padrão como 0 sistema de arquivos 
obtém blocos de dados. Quando um procedimento do siste¬ 
ma de arquivos precisa ler um bloco de dados de usuário, 
um bloco de diretório, um superbloco ou qualquer outro 
tipo de bloco, ele chama get_block, especificando 0 dispo¬ 
sitivo e 0 número de bloco. 

Quando get_block é chamado, ele primeiro examina 0 
cache de blocos para ver se 0 bloco solicitado está aí. Se 
estiver, retorna um ponteiro para ele. Caso contrário, pre¬ 
cisa ler 0 bloco para a memória. Os blocos no cache estão 


encadeados juntos nas listas encadeadas NR_BUF_HASH. 
NR_BUF_HASH é um parâmetro ajustável, junto com 
NR_BUFS, 0 tamanho do cache de blocos. Esses dois são 
configurados em include/minix/config.h. No fim desta se¬ 
ção, diremos algumas palavras sobre otimizar 0 tamanho 
do cache de bloco e a tabela de hash. HASH_MASK é 
NR_BUF_HASH -1. Com 256 listas de hash , a máscara é 
255, portanto, todos os blocos em cada lista têm números 
de bloco que acabam com a mesma cadeia de 8 bits, isto é, 
00000000 , 00000001,.... ou 11111111. 

Em geral, 0 primeiro passo é pesquisar um bloco na 
cadeia de hash, embora haja um caso especial, quando uma 
lacuna em um arquivo esparso está sendo lida, no qual 
essa pesquisa é pulada. Essa é a razão do teste na linha 
21055. Caso contrário, as próximas duas linhas configu¬ 
ram bp para apontar para 0 início da lista em que 0 bloco 
solicitado estaria, se estivesse no cache, aplicando 
HASH_MASK ao número de bloco. O laço na próxima linha 
pesquisa essa lista para ver se 0 bloco pode ser localizado. 
Se for localizado e não estiver em utilização, 0 bloco é re¬ 
movido da lista de LRU. Se já estiver em utilização, ele não 
está na lista de LRU de qualquer maneira. O ponteiro para 
0 bloco localizado é retornado para 0 chamador na linha 
21063. 

Se 0 bloco não está na lista de hash , ele não está no 
cache, então, 0 bloco menos recentemente utilizado da lis¬ 
ta de LRU é tomado. O buffer escolhido é removido de sua 
cadeia de hash , uma vez que está prestes a receber um novo 
número de bloco e, portanto, pertence a uma cadeia de 
hash diferente. Se estiver sujo, ele é regravado em disco na 
linha 21095. Fazer isso com uma chamada a flushall re¬ 
grava quaisquer outros blocos sujos do mesmo dispositivo. 
Os blocos que estão atualmente em utilização nunca são 
escolhidos para expulsão, uma vez que eles não estão na 
cadeia de LRU. Mas os blocos quase nunca serão encontra¬ 
dos como estando em utilização; normalmente um bloco é 
liberado por putjjlock. imediatamente depois de ser utili¬ 
zado. 


Procedimento 

Função 

getjolock 

Buscar um bloco para ler ou gravar 

put_block 

Retornar um bloco previamente solicitado com get_block 

alloc_zone 

Alocar uma nova zona (para fazer um arquivo mais longo) 

free_zone 

Liberar uma zona (quando um arquivo é removido) 

rw_block 

Transferir um bloco entre disco e cache 

invalidate 

Purgar todo 0 cache de blocos para algum dispositivo 

flushall 

Gravar todos os blocos sujos de um dispositivo 

rw_scattered 

Ler ou gravar dados dispersos de ou para um dispositivo 

rmjru 

Remover um bloco de sua cadeia de LRU 


Figura 5-34 Os procedimentos utilizados para gerenciamento de blocos. 



SISTEMAS OPERACIONAIS 319 


Logo que o buffer torna-se disponível, todos os campos, 
incluindo b_dev, são atualizados com os novos parâme¬ 
tros (linhas 21099 a 21104) e o bloco pode ser lido para a 
memória a partir do disco. Entretanto, há duas ocasiões 
em que pode não ser necessário ler o bloco do disco. 
Getjblock é chamado com um parâmetro only_search. Isso 
pode indicar que se trata de uma pré-busca. Durante uma 
pré-busca, um buffer disponível é localizado, gravando o 
conteúdo antigo em disco se necessário, e um novo núme¬ 
ro de bloco é atribuído ao buffer, mas o campo b_dev é 
configurado como NO_DEV para sinalizar que não há até 
agora quaisquer dados válidos nesse bloco. Veremos como 
isso é utilizado quando discutirmos a função rw_scattered. 
Only_search também pode ser utilizado para sinalizar que 
o sistema de arquivos necessita de um bloco simplesmente 
para regravá-lo inteiramente. Nesse caso é um desperdício 
ler primeiro a versão antiga. Em ambos os casos, os parâ¬ 
metros são atualizados, mas a leitura real de disco é omiti¬ 
da (linhas 21107 até 21111). Quando o novo bloco for lido 
para a memória, get_block retoma para seu chamador com 
um ponteiro para ele. 

Suponha que o sistema de arquivos precise de um blo¬ 
co de diretório temporariamente para pesquisar um nome 
de arquivo. O sistema chama getjblock para adquirir o 
bloco de diretório. Depois de pesquisar seu nome de arqui¬ 
vo, o sistema chama putjolock (linha 21119 ) para retor¬ 
nar o bloco para o cache, tornando assim o buffer disponí¬ 
vel no caso de esse ser necessário mais tarde para um bloco 
diferente. 

PutJjlock cuida de colocar o bloco recentemente re¬ 
tornado na lista de LRU e, em alguns casos, de regravá-lo 
no disco. Na linha 21144, toma-se a decisão de colocá-lo 
na frente ou no fundo da lista de LRU, dependendo de 
blockjype , um sinalizador fornecido pelo chamador e que 
informa o tipo do bloco. Os blocos que podem ser necessá¬ 
rios novamente logo vão no final, assim eles permanece¬ 
rão à mão por algum tempo. Os blocos que provavelmente 
não serão necessários novamente logo são colocados na 
frente, onde serão reutilizados de modo rápido. Atualmen¬ 
te, somente superblocos são assim tratados. 

Depois que o bloco foi reposicionado na lista de LRU, 
outra verificação é feita (linhas 21172 e 21173) para ver se 
o bloco deve ser regravado em disco imediatamente. Na 
configuração-padrão, somente superblocos são marcados 
para gravação imediata, mas a única vez que um super- 
bloco é modificado e precisa ser gravado é quando um dis¬ 
co de RAM é redimensionado na inicialização de sistema. 
Nesse caso, a gravação é para o disco de RAM e é imprová¬ 
vel que o superbloco de um disco de RAM precise ser lido 
novamente. Assim, essa capacidade é dificilmente utiliza¬ 
da. Entretanto, a macro ROBUST em include/minix/ 
config.h poder ser editada para indicar gravação imediata 
dos nós-i, dos blocos de diretório e de outros blocos que são 
essenciais ao funcionamento correto do próprio sistema de 
arquivos. 

À medida que o arquivo cresce, de tempos em tempos 
uma nova zona deve ser alocada para armazenar os novos 


dados. O procedimento alloc_zone (linha 21180) cuida de 
alocar novas zonas. Ele faz isso localizando uma zona li¬ 
vre no mapa de bits de zonas. Não há nenhuma necessida¬ 
de de pesquisar pelo mapa de bits se essa será a primeira 
zona em um arquivo; o campo s_zsearch no superbloco, 
que sempre aponta para a primeira zona disponível no dis¬ 
positivo, é consultado. Caso contrário, é feita uma tentati¬ 
va para localizar uma zona perto da última zona existente 
do arquivo atual para manter as zonas de um arquivo jun¬ 
tas. Isso é feito iniciando a pesquisa do mapa de bits a par¬ 
tir dessa última zona (linha 21203). O mapeamento entre 
o número do bit no mapa de bits e o número da zona é 
tratado na linha 21215, com o bit 1 correspondendo à pri¬ 
meira zona de dados. 

Quando um arquivo é removido, suas zonas devem ser 
devolvidas ao mapa de bits. Freejzone (linha 21222) é res¬ 
ponsável por devolver essas zonas. Ilido que faz é chamar 
free_bit , passando o mapa de zonas e o número do bit como 
parâmetros. Free_bit também é utilizado para retomar nós- 
i livres, mas, então, com o mapa de nós-i como o primeiro 
parâmetro, naturalmente. 

O gerenciamento do cache requer leitura e gravação de 
blocos. Para proporcionar uma interface de disco simples, 
o procedimento rwjblock (linha 21243) foi oferecido. Ele 
lê ou grava um bloco. Analogamente, rwjnode existe para 
ler e para gravar nós-i. 

O próximo procedimento no arquivo é invalidate (li¬ 
nha 21280). Ele é chamado quando um disco é desmonta¬ 
do, por exemplo, para remover do cache todos os blocos 
pertencentes ao sistema de arquivos recentemente desmon¬ 
tado. Se isso não for feito, então, quando o dispositivo for 
reutilizado (com um disquete diferente), o sistema de ar¬ 
quivos talvez localize os blocos antigos em vez dos novos. 

Flushall (linha 21295) é chamado pela chamada de 
sistema svxc para descarregar para o disco todos os buffers 
sujos pertencentes a um dispositivo específico. Ele é cha¬ 
mado uma vez para cada dispositivo montado. Ele trata o 
cache de buffers como uma matriz linear, então, todos os 
buffers sujos são localizados, mesmo que estejam atual¬ 
mente em utilização e não estejam na lista de LRU. Todos 
os buffers no cache são varridos e aqueles pertencentes ao 
dispositivo a ser descarregado e que precisam ser gravados 
são adicionados a uma matriz de ponteiros, dirty. Essa 
matriz é declarada como static para mantê-la fora da pi¬ 
lha. Então, ela é passada para rw_scattered. 

Rw_scattered (linha 2131.3) recebe um identificador 
de dispositivo, um ponteiro para uma matriz de ponteiros 
para buffers, o tamanho da matriz e um sinalizador que 
indica se é para ler ou para gravar. A primeira coisa que ele 
faz é classificar a matriz que recebe pelos números de blo¬ 
co, de modo que a operação de leitura ou de gravação seja 
executada em uma ordem eficiente. Ele é chamado com o 
sinalizador WRITING somente a partir da função flushall 
descrita anteriormente. Nesse caso, a origem desses núme¬ 
ros de bloco é fácil de entender. São buffers que contêm 
dados de blocos previamente lidos, mas agora modifica¬ 
dos. A única chamada a rw_scattered para uma operação 



320 TANENBAUM & WOODHULL 


de leitura é de rahead em read.c. Nesse ponto, apenas pre¬ 
cisamos saber que antes de chamar rw_scattered,get_block 
foi chamado repetidamente em modo de pré-busca, reser¬ 
vando, assim, um grupo de buffers, os quais contêm nú¬ 
meros de bloco, mas nenhum parâmetro válido de disposi¬ 
tivo. Isso não é um problema, uma vez que rw_scattered é 
chamado com um parâmetro de dispositivo como um de 
seus argumentos. 

Há uma diferença importante na maneira como o dri¬ 
ver de dispositivo pode responder a uma solicitação de lei¬ 
tura (em oposição a uma gravação) de rw_scattered. Uma 
solicitação para gravar um número de blocos deve ser hon¬ 
rada completamente, mas uma solicitação para ler um 
número de blocos pode ser tratada diferentemente por dri¬ 
vers diferentes, dependendo do que é mais eficiente para o 
driver em particular. Rahead freqüentemente chama 
rw_scattered com uma solicitação para uma lista de blo¬ 
cos que realmente podem não ser necessários, assim, a me¬ 
lhor resposta é obter tantos blocos quanto puderem ser ob¬ 
tidos facilmente, mas não ir descontroladamente buscar 
tudo que há em um dispositivo que pode ter um tempo de 
busca substancial. Por exemplo, o driver de disquete pode 
parar em um limite de trilha e muitos outros drivers so¬ 
mente lerão blocos consecutivos. Quando a leitura está com¬ 
pleta, rw_scattered marca a leitura de blocos, preenchen¬ 
do o campo de número de dispositivo em seus buffers de 
bloco. 

A última função na Figura 5-34 é rmjru (linha 
21387). Essa função é utilizada para remover um bloco da 
lista de LRU. Ela é utilizada somente por get_block nesse 
arquivo, então ela é declarada PR/VATE em vez de PUBLIC 
para ocultá-la de procedimentos fora do arquivo. 

Antes de deixarmos o cache de blocos, precisamos dizer 
algumas palavras sobre o ajuste fino. NR_BUF_HASH de¬ 
ver ser uma potência de 2. Se for maior cpxNR_BUFS, o 
comprimento médio de uma cadeia de hash será menor 
que um. Se houver memória suficiente para um número 
grande de buffers, haverá espaço para um número grande 
de cadeias de hash , então, a escolha normal é tornar 
NR_BUF_HASH a próxima potência de 2 maior que 
NRJBUFS. A listagem no texto mostra configurações de 
512 blocos e de 1024 listas de hash. 0 tamanho ótimo de¬ 
pende de como o sistema é utilizado, uma vez que isso de¬ 
termina quanto deve ser bufferizado. Empiricamente des- 
cobriu-se que aumentar o número de buffers além de 1024 
não melhora o desempenho quando se recompila o siste¬ 
ma MINIX; portanto, aparentemente, isso é grande o sufici¬ 
ente para armazenar os binários para todas as passagens 
do compilador. Para algum outro tipo de trabalho um ta¬ 
manho menor é adequado ou um tamanho maior talvez 
melhore o desempenho. 

Os arquivos binários para o sistema minix no CD-ROM 
são compilados com um cache de blocos muito menor. A 
razão disso é que o binário de distribuição é destinado a 
executar em tantas máquinas quanto possível. Quis-se pro¬ 
duzir uma versão de distribuição do MINIX que poderia ser 
instalada em um sistema, com somente 2MB de memória 


de RAM. Um sistema compilado com um cache de 1024 
blocos requer mais de 2MB de RAM. O binário distribuído 
também inclui cada possível driver de disco rígido e outros 
drivers que podem não ser úteis em uma instalação parti¬ 
cular. A maioria dos usuários vai querer editar include/ 
minix/config.h e recompilar o sistema logo depois da ins¬ 
talação, omitindo drivers desnecessários e aumentando o 
cache de blocos, tanto quanto possível. 

Enquanto no assunto do cache de blocos, indicaremos 
que o limite de 64KB no tamanho de segmento de memó¬ 
ria em processadores Intel de 16 bits torna impossível um 
cache grande nessas máquinas. É possível configurar o sis¬ 
tema de arquivos para utilizar o disco de RAM como um 
cache secundário, armazenando blocos que são empurra¬ 
dos para fora do cache primário. Não discutimos isso aqui 
porque não é necessário em um sistema Intel de 32 bits; 
quando possível, um cache primário grande oferecerá me¬ 
lhor desempenho. Um cache secundário pode ser útil, en¬ 
tretanto, em uma máquina (como um 286) que não tem 
espaço para um cache primário grande dentro do espaço 
de endereço virtual do sistema de arquivos. Um cache se¬ 
cundário deve executar melhor que um disco convencio¬ 
nal de RAM. Um cache armazena somente dados que são 
necessários pelo menos uma vez e, se suficientemente gran¬ 
de, pode fazer uma melhora grande no desempenho do sis¬ 
tema. O “suficientemente grande” não pode ser definido 
de antemão; somente pode ser medido vendo se aumentos 
em tamanho resultam em aumentos no desempenho. 0 
comando time, que mede o tempo utilizado na execução 
de um programa, é uma ferramenta útil quando se tenta 
otimizar um sistema. 

Gerenciamento de Nós-i 

O cache de blocos não é a única tabela que precisa de 
procedimentos de suporte. A tabela de nós-i, também pre¬ 
cisa. Muitos dos procedimentos são semelhantes em fun¬ 
ção aos procedimentos de gerenciamento de blocos. São 
listados na Figura 5-35. 

O procedimento getjnode (linha 21534) é análogo a 
get_block. Quando qualquer parte do sistema de arquivos 
precisa de um nó-i, ele chama get_inode para obtê-lo. 
Getjnode primeiro pesquisa a tabela inode para ver se o 
nó-i já está presente. Se estiver, incrementa o contador de 
uso e retoma um ponteiro para ele. Essa pesquisa está con¬ 
tida nas linhas 21546 a 21556. Se o nó-i não estiver presen¬ 
te na memória, o nó-i é carregado, chamando rwjnode. 

Quando o procedimento que precisava do nó-i termi¬ 
na, o nó-i é retornado, chamando o procedimento 
putjnode (linha 21578), que decrementa a contagem de 
utilização i_count. Se a contagem, então, é zero, o arqui¬ 
vo não está mais em utilização, e o nó-i pode ser removido 
da tabela. Se está sujo, é regravado para o disco. 

Se o campo ijink é zero, nenhuma entrada de dire¬ 
tório está apontando para o arquivo, então, todas as suas 
zonas podem ser liberadas. Note que a contagem de utili¬ 
zação que está indo para zero e o número de vínculos indo 
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Procedimento 

Função 

getjnode 

Buscar um nó-i na memória 

putjnode 

Retornar um nó-i que não é mais necessário 

allocjnode 

Alocar um novo nó-i (para um novo arquivo) 

wipejnode 

Limpar alguns campos em um nó-i 

freejnode 

Liberar um nó-i (quando um arquivo é removido) 

updatejimes 

Atualizar campos de tempo em um nó-i 

rwjnode 

Transferir um nó-i entre memória e disco 

oldjcopy 

Converter o conteúdo de nó-i para gravar em nó-i de disco VI 

newjcopy 

Converter dados lidos do nó-i de disco de sistema de arquivos VI 

dupjnode 

Indicar que outra pessoa está utilizando um nó-i 


Figura 5-35 Os procedimentos utilizados para gerenciamento de nós-i. 


para zero são eventos diferentes, com causas diferentes e 
com conseqüências diferentes. Se o nó-i é para uma cana¬ 
lização, todas as zonas devem ser liberadas, mesmo que o 
número de vínculos possa não ser zero. Isso acontece quan¬ 
do um processo que lê de uma canalização libera a canali¬ 
zação. 

Quando um novo arquivo é criado, um nó-i deve ser 
alocado por allocjnode (linha 21605). O minix permite a 
montagem de dispositivos em modo apenas para leitura, 
então, o superbloco é verificado para assegurar que o dis¬ 
positivo é gravável. Diferentemente das zonas, em que é 
feita uma tentativa de manter as zonas de um arquivo jun¬ 
tas, qualquer nó-i serve. Para poupar o tempo de pesquisar 
o mapa de bits de nós-i, tira-se proveito do campo no su¬ 
perbloco onde o primeiro nó-i não-utilizado foi registrado. 

Depois que o nó-i foi adquirido, get_inode é chamado 
para buscar o nó-i na tabela que está na memória. Então, 
seus campos são inicializados, parcialmente in-line (linhas 
21641 a 21648) e parcialmente utilizando o procedimento 
uipe_inode (linha 21664). Essa divisão particular de tra¬ 
balho foi escolhida porque wipe_inode também é necessá¬ 
rio em outras partes no sistema de arquivos para limpar 
certos campos de nó-i (mas não todos eles). 

Quando um arquivo é removido, seu nó-i é liberado 
chamando freejnode (linha 21684). Tudo o que aconte¬ 
ce aqui é que o bit correspondente no mapa de bits de nós- 
i é configurado como 0, e o registro do superbloco do pri¬ 
meiro nó-i não-utilizado é atualizado. 

A próxima função, updatejimes (linha 21704), é cha¬ 
mada para obter o tempo do relógio de sistema e para alte¬ 
rar os campos de tempo que precisarem ser atualizados. 
Updatejimes também é chamada pelas chamadas de sis¬ 
tema STAT e fstat, então, ela é declarada PUBLIC. 

O procedimento rwjnode (linha 21731) é análogo a 
rw_block. Seu trabalho é buscar um nó-i do disco. Faz seu 
trabalho executando os seguintes passos: 


1. Calcular qual bloco contém o nó-i solicitado. 

2. Ler o bloco chamando getjblock. 

3. Extrair o nó-i e copiá-lo para a tabela inode. 

4. Retornar o bloco, chamando put_block. 

Rwjnode é um pouco mais complexo que o esboço 
básico dado acima, então, algumas funções adicionais são 
necessárias. Primeiro, como obter o tempo atual é caro, 
qualquer necessidade de alterar os campos de tempo no 
nó-i é apenas marcada, ligando-se bits no campo ijupdate 
do nó-i enquanto o nó-i está na memória. Se esse campo 
for diferente de zero quando um nó-i precisar ser gravado, 
updatejimes será chamado. 

Em segundo lugar, a história do minix adiciona uma 
complicação: na antiga versão, VI. do sistema de arquivos 
os nós-i no disco tinham uma estrutura diferente da V2. 
Duas funções, oldjcopy (linha 21774) e newjcopy (li¬ 
nha 21821) cuidam d:ts conversões. A primeira faz a con¬ 
versão entre as informações de nó-i na memória e o for¬ 
mato utilizado pelo sistema de arquivos VI. A segunda faz 
a mesma conversão para discos com sistema de arquivos 
V2. Ambas as funções são chamadas somente a partir desse 
arquivo, então, são declaradas PRNATE. Cada função trata 
as conversões em ambas as direções (do disco para a me¬ 
mória ou da memória para o disco). O minix foi imple¬ 
mentado em sistemas, utilizando uma ordem de byte dife¬ 
rente dos processadores Intel. Cada implementação utiliza 
a ordem de byte nativa em seu disco: o campo sp->native 
no superbloco identifica que ordem é utilizada. Ambas, 
oldjcopy e newjcopy , chamam as funções conv2 e conv4 
para trocar as ordens de byte, se necessário. 

O procedimento dupjnode (linha 21865) simplesmen¬ 
te incrementa a contagem de utilização do nó-i. Ele é cha¬ 
mado quando um arquivo aberto é aberto novamente. Na 
segunda abertura, o nó-i não precisa ser buscado no disco 
novamente. 
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Gerenciamento de Superbloco 

0 arquivo supere contém procedimentos que gerenci¬ 
am o superbloco e os mapas de bits. Há cinco procedimen¬ 
tos nesse arquivo, listados na Figura 5-36. 

Quando um nó-i ou uma zona é necessário, allocjnode 
ou alloc_zone é chamada, como vimos acima. Ambas cha¬ 
mam alloc_bit (linha 21926 ) para realmente pesquisar o 
mapa de bits relevante. A pesquisa envolve três laços ani¬ 
nhados como segue: 

1. O externo faz um laço em todos os blocos de um 
mapa de bits. 

2. 0 do meio faz um laço em todas as palavras de um 
bloco. 

3. 0 interno faz um laço em todos os bits de uma 
palavra. 

0 laço do meio funciona vendo se a palavra atual é igual 
ao complemento de um de zero, isto é, uma palavra com¬ 
pleta cheia de ls. Se for, ela não tem nós-i ou zonas livres, 
então, a próxima palavra é tentada. Quando uma palavra 
com um valor diferente é localizada, ela deve ter pelo me¬ 
nos um bit 0 nela; então, o laço interno é iniciado para 
localizar o bit livre (i. e., 0). Se todos os blocos forem ten¬ 
tados sem êxito, não há nós-i ou zonas livres, então, o có¬ 
digo NO_BIT (0) é retornado. Pesquisas como essa podem 
consumir muito tempo do processador, mas o uso dos cam¬ 
pos no superbloco que apontam para o primeiro nó-i e zona 
não-utilizados, passado para alloc_bit em origin , ajuda a 
manter essas pesquisas curtas. 

Liberar um bit é mais simples que alocar, porque ne¬ 
nhuma pesquisa é necessária. Freejoit (linha 22003) cal¬ 
cula qual bloco do mapa de bits contém o bit a liberar e 
configura o bit adequado como 0 chamando get_block, 
para zerar o bit na memória e, então, chamar put_block. 

O próximo procedimento, get_super (linha 22047), é 
utilizado para pesquisar a tabela de superbloco para um 
dispositivo específico. Por exemplo, quando um sistema de 
arquivos estiver para ser montado, é necessário verificar se 
ele já não está montado. Essa verificação pode ser executa¬ 
da solicitando a get_super para localizar o dispositivo do 
sistema de arquivos. Se o dispositivo não for localizado, 
então, o sistema de arquivos não está montado. 

A próxima função, mounted (linha 22067), é chama¬ 
da somente quando um dispositivo de bloco é fechado. 


Normalmente, todos os dados em cache para um dispositi¬ 
vo são descartados quando ele é fechado. Mas, se acontecer 
de o dispositivo estar montado, isso não é desejável. Moun¬ 
ted é chamada com um ponteiro para o nó-i de um dispo¬ 
sitivo. Ela simplesmente retorna TRUE se o dispositivo for 
o dispositivo-raiz ou se for um dispositivo montado. 

Por fim, temos read_super (linha 22088). Essa é par¬ 
cialmente análoga a rw_block e rw_inode , mas é chama¬ 
da somente para ler. A gravação de um superbloco não é 
necessária na operação normal do sistema. Read_super 
verifica a versão do sistema de arquivos do qual acaba de 
ler e executa conversões, se necessário; então, a cópia do 
superbloco na memória terá a estrutura-padrão mesmo 
quando lida de um disco com uma diferente estrutura de 
superbloco. 

Gerenciamento de Descritores de Arquivos 

O MiNix contém procedimentos especiais para gerenci¬ 
ar descritores de arquivos e a tabela filp (veja a Figura 5- 
33). Eles estão contidos no arquivo filedes.c. Quando um 
arquivo é criado ou aberto, um descritor de arquivo e uma 
entrada filp livres são necessários. O procedimento getjd 
(linha 22216) é utilizado para localizá-los. Entretanto, eles 
não são marcados como em utilização, porque muitas ve¬ 
rificações devem ser feitas antes de saber-se com certeza 
que CREAT ou OPEN tiveram sucesso. 

Get Jilp (linha 22263) é utilizada para ver se um des¬ 
critor de arquivos está ao alcance e, se estiver, retorna seu 
ponteiro filp. 

O último procedimento nesse arquivo é findJilp (li¬ 
nha 22277). Ele é necessário para saber quando um pro¬ 
cesso está gravando em uma canalização quebrada (i. e., 
em uma canalização não-aberta para leitura por qualquer 
outro processo). Ele localiza leitores potenciais por uma 
pesquisa de força bruta da tabela//#?. Se não puder locali¬ 
zar um, a canalização é quebrada, e a gravação falha. 

Bloqueio de Arquivos 

As funções de bloqueio de registro do POSix são mostra¬ 
das na Figura 5-37. Uma parte de um arquivo pode ser blo¬ 
queada para leitura e gravação ou para gravação somente, 
por uma chamada fcntl, especificando uma solicitação 
F_SETLK ou FJSETLKW. Se existe ou não um bloqueio so- 


Procedimento 

Função 

alloc_bit 

Alocar um bit do mapa de zonas ou de nós-i 

free_bit 

Liberar um bit do mapa de zonas ou de nós-i 

get_super 

Procurar a tabela de superbloco para um dispositivo 

mounted 

Informar se um nó-i dado está em um sistema de arquivos montado (ou raiz) 

read_super 

Ler um superbloco 


Figura 5-36 Os procedimentos utilizados para gerenciar o superbloco e os mapas de bits. 
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Operação 

Significado 

F_SETLK 

Bloqueia região tanto para leitura quanto para gravação 

F_SETLKW 

Bloqueia região para gravação 

F_GETLK 

Informa se a região está bloqueada 


Figura 5-37 Operações de bloqueio de registro consultivas do posix. Essas operações são solicitadas 
utilizando a chamada de sistema fcntl. 


bre uma parte de um arquivo, isso pode ser determinado, 
utilizando a solicitação F_GETLK. 

Há somente duas funções no arquivo lock.c. Lock_op 
(linha 22319) é chamada pela chamada de sistema fcntl 
com um código para uma das operações mostradas na Fi¬ 
gura 5-37. Ela faz alguma verificação de erro para certifi¬ 
car-se de que a região especificada é válida. Quando um 
bloqueio está sendo configurado, ele não deve conflitar um 
bloqueio existente; e quando um bloqueio está sendo lim¬ 
po, um bloqueio existente não deve ser dividido em dois. 
Quando qualquer bloqueio é limpo, a outra função nesse 
arquivo, lock_revive (linha 22463), é chamada. Ela des¬ 
perta todos os processos que estão bloqueados, esperando 
bloqueios. Essa estratégia é um acordo; tomaria código extra 
para descobrir exatamente quais processos estavam espe¬ 
rando um bloqueio particular ser liberado. Esses processos 
que ainda estão esperando um arquivo bloqueado bloque¬ 
arão novamente quando iniciarem. Essa estratégia é base¬ 
ada em uma suposição de que o bloqueio será utilizado 
raramente. Se um banco de dados multiusuário importan¬ 
te tivesse de ser construído sobre um sistema mintx, talvez 
fosse desejável reimplementar isso. 

Lockjrevive também é chamada quando um arquivo 
bloqueado é fechado, como talvez aconteça, por exemplo, 
se um processo é eliminado antes de terminar de utilizar 
um arquivo bloqueado. 

5.7.3 Programa Principal 

0 laço principal do sistema de arquivos está contido no 
arquivo main.c, iniciando na linha 22537. Estruturalmen¬ 
te, ele é muito semelhante ao laço principal do gerencia¬ 
dor de memória e das tarefas de E/S. A chamada a get_work 
espera a próxima mensagem de solicitação chegar (a me¬ 
nos que um processo previamente suspenso em uma cana¬ 
lização ou terminal agora possa ser tratado). Ele também 
configura uma variável global, who , para o número de en¬ 
trada da tabela de processos do chamador e outra variável 
global, fs_call, para o número da chamada de sistema a 
ser executada. 

Uma vez de volta ao laço principal, três sinalizadores 
são configurados: fp aponta para a entrada da tabela de 
processos do chamador, super juser diz se o chamador é o 
superusuário ou não e dont_reply é inicializado como FAL¬ 
SE. Então, vem a atração principal — a chamada ao pro¬ 
cedimento que executa a chamada de sistema. 0 procedi¬ 


mento a chamar é selecionado, utilizando fs_call como 
um índice na matriz de ponteiros de procedimento, 
call_vector. 

Quando o controle volta para o laço principal, se 
dont_reply tiver sido configurado, a resposta é inibida (p. 
ex., um processo bloqueou tentando ler de uma canaliza¬ 
ção vazia). Caso contrário, uma resposta é enviada. A de¬ 
claração final no laço principal foi projetada para detectar 
que um arquivo está sendo lido seqüencialmente e carre¬ 
gar o próximo bloco no cache antes de ele ser realmente 
solicitado para melhorar o desempenho. 

0 procedimento get_work (linha 22572) verifica se 
qualquer procedimento previamente bloqueado agora foi 
reanimado. Se tiver sido, esse tem prioridade sobre novas 
mensagens. Somente se não houver trabalho interno a fa¬ 
zer é que o sistema de arquivos chama o kernel para obter 
uma mensagem na linha 22598. 

Depois que uma chamada de sistema foi completada, 
com êxito ou não, uma resposta é enviada de volta para o 
chamador por reply (linha 22608). O processo pode ter sido 
eliminado por um sinal, então, o código de status retoma¬ 
do pelo kernel é ignorado. Nesse caso, não há nada a ser 
feito de qualquer jeito. 

Funções de Inicialização 

O restante de main. c consiste em funções que são utili¬ 
zadas somente na inicialização do sistema. Antes de o sis¬ 
tema de arquivos entrar em seu laço principal, ele se inici¬ 
aliza chamando fsjnit (linha 22625) que, por sua vez, 
chama várias outras funções para inicializar o cache de 
blocos, para obter os parâmetros de inicialização, para car¬ 
regar o disco de RAM se necessário e para carregar o super- 
bloco do dispositivo-raiz. O próximo passo é inicializar a 
parte do sistema de arquivos na tabela de processos para 
todas as tarefas e servidores até init (linhas 22643 a 22654). 
Por fim, testes são feitos em algumas constantes importan¬ 
tes, para ver se fazem sentido, e uma mensagem é enviada 
para a tarefa de memória com o endereço da parte do siste¬ 
ma de arquivos na tabela de processos para utilização pelo 
programa/w. 

A primeira função chamada por fsjnit é buf Jiool (li¬ 
nha 22679), que constrói as listas encadeadas utilizadas 
pelo cache de blocos. A Figura 5-31 mostra 0 estado nor¬ 
mal do cache de blocos, em que todos os blocos estão enca¬ 
deados, tanto na cadeia de LRU como na cadeia de hash. 
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Ele pode ser útil para ver como a situação da Figura 5-31 
realiza-se. Imediatamente depois de o cache ser inicializa- 
do por huf _pool, todos os buffers estarão na cadeia de LRU 
e todos serão encadeados na cadeia 0 de hash, como na 
Figura 5-38(a). Quando um buffer é solicitado e enquanto 
estiver em utilização, temos a situação da Figura 5-38(b), 
em que vemos que um bloco foi removido da cadeia de 
LRU e está agora em uma cadeia de hash diferente. Nor¬ 
malmente, os blocos são liberados e retomados à cadeia de 
LRU imediatamente. A Figura 5-38(c) mostra a situação 
depois que o bloco foi retornado à cadeia de LRU. Embora 
não esteja mais em utilização, ele pode ser acessado nova¬ 
mente para oferecer os mesmos dados, se for necessário, e, 
então, é retido na cadeia de hash. Depois que o sistema 
esteve em operação por algum tempo, provavelmente qua¬ 
se todos os blocos terão sido utilizados e distribuídos alea¬ 


toriamente entre as diferentes cadeias de hash. Então, a ca¬ 
deia de LRU ficará parecida com a Figura 5-31- 

A próxima função é get_bootJ)arameters (linha 
22706). Ela envia uma mensagem à tarefa de sistema, pe¬ 
dindo-lhe uma cópia dos parâmetros de inicialização. Es¬ 
ses são necessários para a função seguinte, load_ram (li¬ 
nha 22722), que aloca espaço para um disco de RAM. Se os 
parâmetros de inicialização especificarem 

rootdev = ram 

o sistema de arquivos do dispositivo-raiz será copiado do 
dispositivo nomeado por ramimagedev para o disco de 
RAM, bloco por bloco, iniciando com o bloco de inicializa¬ 
ção, sem interpretação das várias estruturas de dados do 
sistema de arquivos. Se o parâmetro de inicialização ram- 
size for menor que o tamanho do sistema de arquivos do 
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Figura 5-38 Inicialização do cache de blocos, (a) Antes de qualquer buffer ser utilizado, (b) 
Depois que um bloco foi solicitado, (c) Depois que o bloco foi liberado. 
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dispositivo-raiz, o disco de RAM será feito grande o sufici¬ 
ente para armazená-lo. Se ramsize especificar um tama¬ 
nho maior que o sistema de arquivos do dispositivo de ini¬ 
cialização, o tamanho especificado será alocado, e o siste¬ 
ma de arquivos do disco de RAM será ajustado para utilizar 
inteiramente o tamanho especificado (linhas 22819 a 
22825) A chamada a put_block na linha 22825 é o único 
momento em que o sistema de arquivos grava um super- 
bloco. 

Loadjram aloca espaço para um disco de RAM vazio 
se um ramsize não-zero for especificado. Nesse caso, uma 
vez que nenhuma estrutura do sistema de arquivos foi co¬ 
piada, o dispositivo de RAM não pode ser utilizado como 
um sistema de arquivos até que seja inicializado pelo co¬ 
mando mkfs. Aternativamente, esse disco de RAM poderá 
ser utilizado para um cache secundário, se o suporte para 
isso for compilado no sistema de arquivos. 

A última função em main.c é load_super (linha 
22832). Ela inicializa a tabela de superbloco, e carrega o 
superbloco do dispositivo-raiz. 

5.7.4 Operações em Arquivos 
Individuais 

Nesta seção, veremos as chamadas de sistema que ope¬ 
ram em arquivos individuais um por vez (em oposição a, 
digamos, operações em diretórios). Iniciaremos com a 
maneira como os arquivos são criados, abertos e fechados. 
Depois, examinaremos em algum detalhe o mecanismo 
pelo qual os arquivos são lidos e gravados. Em seguida, 
veremos como as canalizações e as operações nelas dife¬ 
rem daquelas em arquivos. 

Criando, Abrindo e Fechando Arquivos 

0 arquivo open.c contém o código para seis chamadas 
de sistema: CRKAT, OPKN, MKNOD, MKDIR, CI.OSE e LSEEK. Exa¬ 
minaremos CREAT e OPK.\ juntas e, então, veremos cada uma 
da outras. 

Em versões mais antigas do UNIX, as chamadas CREAT e 
OPEN tinham propósitos distintos. Tentar abrir um arquivo 
que não existia era um erro e um novo arquivo tinha de ser 
criado com CREAT, que também poderia ser utilizada para 
truncar um arquivo existente para comprimento zero. A 
necessidade de duas chamadas distintas não está mais pre¬ 
sente em sistemas posix, entretanto sob o posix, a chama¬ 
da OPEN agora permite criar um novo arquivo ou truncar 
um arquivo antigo, então, a chamada CREAT agora repre¬ 
senta um subconjunto das possíveis utilizações da chama¬ 
da OPEN e é realmente necessária apenas para compatibili¬ 
dade com programas mais antigos. Os procedimentos que 
tratam CREAT e OPEN são do_creat (linha 22937) e do_open 
(linha 22951). (Como no gerenciador de memória, no sis¬ 
tema de arquivos é utilizada a convenção de que a chama¬ 
da de sistema XXX é executada pelo procedimento do_xxx .) 
A abertura ou a criação de um arquivo envolve três passos: 


1. Localizar o nó-i (alocar e iniciaiizar se o arquivo 
for novo). 

2. Localizar ou criar a entrada de diretório. 

3. Configurar e retornar um descritor de arquivo para 
o arquivo. 

Ambas as chamadas CREAT e open fazem duas coi¬ 
sas: buscam o nome de um arquivo e, então, chamam 
cornmon jopen para cuidar das tarefas comuns a ambas 
as chamadas. 

Commonjoperi (linha 22975) inicia certificando-se de 
que entradas livres da tabela de descritores de arquivos e 
da tabela/?//) estão disponíveis. Se a função chamada espe¬ 
cificou a criação de um novo arquivo (chamando com o 
bit OjCREAT ligado), neujnode é chamada na linha 
22998. Neu'_node retornará um ponteiro para um nó-i 
existente se a entrada de diretório já existir; caso contrário, 
criará tanto uma nova entrada de diretório como o nó-i. Se 
o nó-i não puder ser criado, neujnode configura a variá¬ 
vel global err_code. Um código de erro nem sempre signi¬ 
fica um erro. Se neujnode localizar um arquivo existen¬ 
te, o código de erro retornado indicará que o arquivo exis¬ 
te, mas nesse caso esse erro é aceitável (linha 23001). Se o 
bit OjCREAT não estiver ligado, é feita uma pesquisa do 
nó-i, utilizando um método alternativo, a função eat_path 
em path.c, que posteriormente discutiremos. Nesse ponto, 
o importante é entender que se um nó-i não for localizado 
nem puder ser criado com êxito, common_open termina¬ 
rá com um erro antes de ter alcançado a linha 23010. Caso 
contrário, a execução continua aqui com a atribuição de 
um descritor de arquivo e reivindicando uma entrada na 
tabela/?//). Seguindo-se a isso, se um novo arquivo acabou 
de ser criado, as linhas 23017 a 23094 são puladas. 

Se o arquivo não for novo, então, o sistema de arquivos 
deve testar para ver de que tipo o arquivo é, seu modo e 
assim por diante, a fim de determinar se ele pode ser aber¬ 
to. A chamada a forbidden na linha 23018 primeiro faz 
uma verificação geral dos bits rux. Se o arquivo for co¬ 
mum e common jopen for chamado com o bit OJTRUNC 
ligado, ele é truncado para comprimento zero e forbidden 
é chamada novamente (linha 23024), dessa vez para asse¬ 
gurar que o arquivo pode ser gravado. Se os direitos permi¬ 
tirem, wipejnode e rujinode são chamados para reinici¬ 
alizar o nó-i e gravar no disco. Outros tipos de arquivo (di¬ 
retórios, arquivos especiais e canalizações nomeadas) são 
submetidos aos testes apropriados. No caso de um disposi¬ 
tivo, é feita uma chamada na linha 23053 (utilizando a 
estrutura dmap ) à rotina apropriada para abrir o disposi¬ 
tivo. No caso de uma canalização nomeada, é feita uma 
chamada z.pipe jopen (linha 23060) e são feitos vários tes¬ 
tes pertinentes. 

O código de common jopen, assim como muitos ou¬ 
tros procedimentos do sistema de arquivos, contém uma 
quantidade grande de código que verifica vários erros e 
combinações ilegais. Embora não-fascinante, esse código 
é essencial para ter um sistema de arquivos livre de erros e 
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robusto. Se algo estiver errado, o descritor de arquivo e o 
slot filp previamente alocado são desalocados, e o nó-i é 
liberado (linhas 23098 a 23101). Nesse caso, o valor retor¬ 
nado por common_open será um número negativo, indi¬ 
cando um erro. Se não houver nenhum problema, o des¬ 
critor de arquivo, que é um valor positivo, será retornado. 

Esse é um bom lugar para discutir em mais detalhes a 
operação de new_node (linha 23111), que faz a alocação 
do nó-i e a entrada do nome de caminho no sistema de 
arquivos para as chamadas creat e OPEN. Ela também é 
utilizada para as chamadas mkxod e mkdir, ainda a serem 
discutidas. A declaração na linha 23128 analisa sintatica¬ 
mente o nome de caminho (i. e., pesquisa-o componente 
por componente) até o diretório final; a chamada a ad- 
vance, três linhas mais adiante, tenta ver se o componente 
final pode ser aberto. 

Por exemplo, na chamada 

fd = creat(”/usr/ast/foobar”, 0755); 

last_dir tenta carregar o nó-i para /usr/ast nas tabelas e 
retoma um ponteiro para ele. Se o arquivo não existir, ne¬ 
cessitaremos desse nó-i brevemente para adicionar foobar 
ao diretório. Todas as outras chamadas de sistema que adi¬ 
cionam ou excluem arquivos também utilizam last_dir 
para primeiro abrir o diretório final no caminho. 

Se new_node descobre que o arquivo não existe, ela 
chama allocjnode na linha 23134 para alocar e carregar 
um novo nó-i, retornando um ponteiro para ele. Se não 
restar nenhum nó-i livre, new_node falha e retorna 
NILJNODE. 

Se um nó-i puder ser alocado, a operação continuará 
na linha 23144, preenchendo alguns campos, gravando- 
os de volta em disco e inserindo o nome de arquivo no dire¬ 
tório final (linha 23149). Novamente vemos que o sistema 
de arquivos deve constantemente verificar novos erros e, 
ao encontrar um, cuidadosamente liberar todos os recur¬ 
sos, como nós-i e blocos que ele está segurando. Se preci¬ 
sássemos simplesmente preparar o minix para gerar uma 
pane quando esgotássemos, digamos, os nós-i, em vez de 
desfazer todos os efeitos da chamada atual e retornar um 
código de erro para o chamador, o sistema de arquivos se¬ 
ria consideravelmente mais simples. 

Como mencionado acima, as canalizações exigem tra¬ 
tamento especial. Se não houver pelo menos um par lei¬ 
tor/gravador para uma canalização, pipe_operi (linha 
23176) suspende 0 chamador. Caso contrário, chama rele- 
ase, que procura na tabela de processos por processos que 
estão bloqueados na canalização. Se for bem-sucedida, os 
processos são reanimados. 

A chamada mkxod é tratada por do_mknod (linha 
23205). Esse procedimento é semelhante a do_creat, exce¬ 
to que termina de criar 0 nó-i e faz uma entrada de dire¬ 
tório para ele. De fato, a maior parte do trabalho é feita 
pela chamada a new_node na linha 23217. Se 0 nó-i já 
existir, um código de erro será retornado. Esse é 0 mesmo 
código de erro que era um resultado aceitável de new_node 
quando foi chamado por common_open\ nesse caso, en¬ 


tretanto, 0 código de erro é passado de volta para 0 chama¬ 
dor, que presumivelmente agirá assim. A análise caso a caso 
que vimos em common_open não é necessária aqui. 

A chamada mkdir é tratada pela função do_mkdir (li¬ 
nha 23226). Como com as outras chamadas de sistema que 
discutimos aqui, new_node desempenha um papel impor¬ 
tante. Os diretórios, diferentemente dos arquivos, sempre 
têm vínculos e nunca estão completamente vazios porque 
cada diretório deve conter duas entradas criadas no mo¬ 
mento da sua criação: as entradas e que se referem 
ao próprio diretório e ao seu diretório-pai. Há um limite 
para 0 número de vínculos que um arquivo pode ter, 
LÍNKJÍAX (definida em include/límits.h como 127 parao 
sistema MINIX padrão). Uma vez que a referência a um di¬ 
retório-pai em um filho é um vínculo para 0 pai, a primei¬ 
ra coisa que do_mkdir faz é ver se é possível fazer outro 
vínculo no diretório-pai (linha 23240). Uma vez que esse 
teste foi passado, new_node é chamado. Se newjnode for 
bem-sucedido, então, as entradas de diretório para e 

são feitas (linhas 23261 e 23262). Túdo isso é simples 
e direto, mas poderia haver falhas (p. ex., se 0 disco estiver 
cheio) e para evitar confusão providenciou-se a possibili¬ 
dade de desfazer as etapas iniciais do processo, caso elas 
não puderem ser completadas. 

Fechar um arquivo é mais fácil que abrir. O trabalho é 
feito por do_close (linha 23286). As canalizações e os ar¬ 
quivos especiais necessitam de alguma atenção, mas para 
arquivos comuns, quase tudo que precisa ser feito é decre- 
mentar 0 contador filp e verificar se ele é zero, caso em que 
0 nó-i é retornado com put_inode. O passo final é remover 
quaisquer bloqueios e resumir qualquer processo que pode 
ter sido suspenso, esperando um bloqueio no arquivo ser 
liberado. 

Note que retornar um nó-i significa que seu contador 
na tabela inode é decrementado, de modo que ele possa 
eventualmente ser removido da tabela. Essa operação não 
tem nada a ver com liberar 0 nó-i (i. e., ligar um bit no 
mapa de bits que diz que ele está disponível). 0 nó-i so¬ 
mente é liberado quando 0 arquivo é removido de todos os 
diretórios. 

0 procedimento final em open.c é do_lseek (linha 
23367). Quando uma busca é feita, esse procedimento é 
chamado para configurar a posição de arquivo para um 
novo valor. Na linha 23394, a leitura antecipada é inibida; 
uma tentativa explícita de buscar uma posição em um ar¬ 
quivo é incompatível com 0 acesso seqüencial. 

Lendo um Arquivo 

Uma vez que um arquivo foi aberto, ele pode ser lido ou 
gravado. Muitas funções são utilizadas tanto durante a lei¬ 
tura como durante a gravação. Essas funções estão locali¬ 
zadas no arquivo read.c. Discutiremos essas primeiro e, 
então, prosseguiremos para 0 arquivo seguinte, write.c , para 
ver 0 código especificamente utilizado para gravação. Lei¬ 
tura e gravação diferem sob vários aspectos, mas têm tan¬ 
tas semelhanças que tudo que é solicitado de do_read (li- 



SISTEMAS OPERACIONAIS 327 


nha 23434) é chamar o procedimento comum read_write 
com um sinalizador configurado como READING. Veremos 
na próxima seção que do_write é igualmente simples. 

Readjirite começa na linha 23443. Há algum código 
especial nas linhas 23459 a 23462 que é utilizado pelo ge¬ 
renciador de memória para fazer o sistema de arquivos 
carregar segmentos inteiros no espaço de usuário para ele. 
Chamadas normais são processadas, iniciando na linha 
23464. Alguma verificação de validade segue-se (p. ex., lei¬ 
tura de um arquivo aberto somente para escrita) e algu¬ 
mas variáveis são inicializadas. As leituras de arquivos es¬ 
peciais de caractere não seguem pelo cache de blocos, as¬ 
sim, são filtradas na linha 23498. 

Os testes nas linhas 23507 a 23518 aplicam-se somente 
a gravações e têm a ver com arquivos que podem ficar mai¬ 
ores do que o dispositivo pode armazenar, ou gravações que 
criarão uma lacuna no arquivo, gravando para além do 
fim do arquivo. Como discutimos na visão geral do mintx, 
a presença de múltiplos blocos por zona causa problemas 
que devem ser tratados explicitamente. As canalizações tam¬ 
bém são especiais e são verificadas. 

O núcleo do mecanismo de leitura, pelo menos para 
arquivos comuns, é o laço que inicia na linha 23530. Esse 
laço quebra a solicitação em pedaços, cada um dos quais 
se ajusta em um único bloco de disco. Um pedaço começa 
na posição atual e estende-se até que uma das seguintes 
condições seja satisfeita: 

1. Todos os bytes foram lidos. 

2. Um limite de bloco foi encontrado. 

3. O fim do arquivo é atingido. 

Essas regras significam que um pedaço nunca requer dois 
blocos de disco para satisfazê-lo. A Figura 5-39 mostra três 
exemplos de como o tamanho do pedaço é determinado, 
para tamanhos de 6, de 2 e de 1 bytes, respectivamente. O 
cálculo real é feito nas linhas 23632 a 23641. 


A leitura real do pedaço é feita por ru jchunk. Quando 
o controle retorna, vários contadores e ponteiros são incre¬ 
mentados e, a próxima iteração começa. Quando o laço 
termina, a posição de arquivo e outras variáveis podem ser 
atualizadas (p. ex., ponteiros de canalizações). 

Por fim, se a leitura antecipada for chamada, o nó-i e a 
posição a serem lidos são armazenados em variáveis glo¬ 
bais, de modo que depois que a mensagem de resposta é 
enviada para o usuário, o sistema de arquivos pode come¬ 
çar a trabalhar para obter o próximo bloco. Em muitos 
casos, o sistema de arquivos bloqueará, esperando o próxi¬ 
mo bloco de disco, tempo durante o qual o processo de usu¬ 
ário será capaz de trabalhar nos dados que acabou de rece¬ 
ber. Esse arranjo sobrepõe-se ao processamento e à E/S e 
pode melhorar o desempenho substancialmente. 

O procedimento rw_chunk (linha 23613) está preocu¬ 
pado em tomar um nó-i e uma posição de arquivo, conver¬ 
tê-los em um número físico de bloco de disco e solicitar a 
transferência desse bloco (ou uma parte dele) para o espa¬ 
ço do usuário. O mapeamento da posição de arquivo rela¬ 
tiva ao endereço físico de disco é feito por read_map , que 
entende de nós-i e de blocos indiretos. Para um arquivo 
comum, as variáveis b e dev nas linhas 23637 e 23638 con¬ 
têm o número físico do bloco e o número de dispositivo, 
respectivamente. A chamada a ge/_block na linha 23660 é 
onde o manipulador de cache é solicitado a localizar o blo¬ 
co, lendo-o se necessário. 

Uma vez que temos um ponteiro para o bloco, a cha¬ 
mada a sys_j:opy na linha 23670 cuida de transferir a par¬ 
te solicitada dele para o espaço do usuário. O bloco, então, 
é liberado por put_block, de modo que pode ser expulso do 
cache mais tarde, quando chegar a hora. (Depois de ser 
adquirido por getjblock, ele não estará na fila de LRU e 
não será retornado aí enquanto o contador no cabeçalho 
do bloco mostrar que ele está em utilização, portanto, ele 
ficará isento de expulsão; put_block decrementa o conta- 
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Figura 5-39 Três exemplos de como o primeiro tamanho de pedaço é determinado para um arquivo de 10 bytes. O 
tamanho de bloco é 8 bytes e o número de bytes solicitado é 6. O pedaço é mostrado sombreado. 
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dor e retorna o bloco à fila de LRU quando o contador atin¬ 
gir zero.) O código na linha 23680 indica se uma operação 
de gravação preencheu o bloco. Entretanto, o valor passa¬ 
do para put_block em n não afeta como o bloco é coloca¬ 
do na fila; todos os blocos agora estão colocados no fim da 
cadeia de LRU. 

Read_map (linha 23689) converte uma posição lógi¬ 
ca de arquivo para o número físico de bloco inspecionando 
o nó-i. Para blocos próximos o suficiente do começo do 
arquivo, eles caem dentro de uma das primeiras sete zonas 
(aquele exatamente no nó-i), um cálculo simples é sufici¬ 
ente para determinar qual zona é necessária e então qual 
bloco. Para blocos adiante no arquivo, um ou mais blocos 
indiretos podem precisar ser lidos. 

Rdjndír (linha 23753) e' chamado para ler um bloco 
indireto. Ele foi feito como um procedimento separado por¬ 
que há diferentes formatos que os dados podem assumir 
no disco, dependendo da versão do sistema de arquivos e 
do hardware em que o sistema de arquivos foi escrito. As 
confusas conversões são feitas aqui, se necessário; então, o 
restante do sistema de arquivos vê os dados em apenas um 
formato. 

Read_ahead (linha 23786) converte a posição lógica 
para um número físico de bloco, chama get_block para 
certificar-se de que o bloco está no cacbe (ou o traz) e, en¬ 
tão, retorna o bloco imediatamente. Esse procedimento não 
pode fazer nada com o bloco, afinal de contas. Apenas quer 
melhorar a chance de que o bloco esteja à mão se este últi¬ 
mo precisar ser utilizado em seguida. 

Note que read_abead é chamado somente a partir do 
laço principal em main. Ele não é chamado como parte 
do processamento da chamada de sistema READ. É impor¬ 
tante saber que a chamada a read_ahead é executada de¬ 
pois que a resposta é enviada, de modo que o usuário será 
capaz de continuar executando mesmo se o sistema de ar¬ 
quivos precisar esperar um bloco de disco enquanto faz lei¬ 
tura adiante. 

Read_aheade m si é projetado somente para pedir mais 
um bloco. Ele chama a última função em read.c, rahead. 
para realmente fazer o trabalho. Rahead (linha 23805) tra¬ 
balha de acordo com a teoria de que se um pouco a mais é 
bom, um monte a mais é melhor ainda. Uma vez que dis¬ 
cos e outros dispositivos de armazenamento freqüentemente 
levam um tempo relativamente longo para localizar o pri¬ 
meiro bloco solicitado, mas, então, podem ler de modo re¬ 
lativamente rápido um número de blocos adjacentes, é pos¬ 
sível obter muitos mais blocos lidos com um pequeno es¬ 
forço adicional. Uma solicitação de pré-busca é feita para 
get_block, que prepara o cache de blocos para receber di¬ 
versos blocos de uma vez. Então, rw_scatteredé chamado 
com uma lista de blocos. Já discutimos isso antes; lembre- 
se de que quando os drivers de dispositivo são realmente 
chamados por rw_scattered , cada um é livre para respon¬ 
der somente à quantidade de solicitações que ele pode tra¬ 
tar de maneira eficiente. Tudo isso parece complicado, mas 


as complicações tornam possível uma aceleração signifi¬ 
cativa em aplicativos que lêem grandes quantidades de 
dados do disco. 

A Figura 5-40 mostra as relações entre alguns procedi¬ 
mentos importantes envolvidos na leitura de um arquivo, 
em particular, quem chama quem. 

Gravando um Arquivo 

O código para gravar arquivos está em uri/e.c. A grava- ; 
ção de um arquivo é semelhante à leitura, e do_write (li- \ 
nha 24025) simplesmente chama read_write com o sina- 1 
lizador WRITING. Uma diferença importante entre leitura l 
e gravação é que a gravação requer alocar blocos de disco j 
novos. Write_map (linha 24036) é análogo a read_map, . 
exceto que em vez de pesquisar números físicos de bloco j 
no nó-i e seus blocos indiretos, ele insere novos aí (para ser í 
preciso, ele insere números de zona. não números de blo- í 
co). 

O código de writejnap é longo e detalhado porque deve 
lidar com vários casos. Se a zona a ser inserida estiver per¬ 
to do começo do arquivo, ela simplesmente insere no nó-i j 
(linha 24058). | 

O pior caso é quando um arquivo excede o tamanho ] 
que pode ser tratado por um bloco indireto simples, de modo j 
que um bloco indireto duplo agora é solicitado. Em segui- j 
da, um bloco indireto simples deve ser alocado, e seu ende- I 
reço colocado no bloco indireto duplo. Como com a leitu- j 
ra, um procedimento separado, ur_indir, é chamado. Se o j 
bloco indireto duplo for adquirido corretamente, mas o dis- í 
co estiver cheio, então, o bloco indireto simples não pode ; 
ser alocado; sendo assim, o duplo deve ser devolvido para ' 
evitar corromper o mapa de bits. : 

Novamente, se pudéssemos apenas desistir e aceitar a ' 
pane nesse ponto, o código seria muito mais simples. En- ; 
tretanto. do ponto de vista do usuário, é muito mais ami- \ 
gável que o esgotamento do espaço em disco simplesmente ; 
retornasse um erro de WRITE, em vez de “travar" o compu¬ 
tador com um sistema de arquivos corrompido. 

Wrjndir (linha 24127) chama uma das rotinas de ; 
conversão, conv2 ou conv4 para fazer qualquer conversão 
de dados necessária e coloca um novo número de zona em 
um bloco indireto. Lembre-se de que o nome dessa função, 
como os nomes de muitas outras funções que envolvem 
leitura e gravação, não é literalmente verdadeiro. A grava- , 
ção real para o disco é tratada pelas funções que mantêm o 
cache de blocos. 

O próximo procedimento em write.c é clear_zone (li¬ 
nha 24149), que cuida do problema de apagar blocos que 
estão repentinamente no meio de um arquivo. Isso aconte¬ 
ce quando uma busca é feita além do fim de um arquivo, 
seguida por uma gravação de alguns dados. Felizmente, 
essa situação não ocorre com muita frequência 

Newjolock (linha 24190) é chamado por rwjchunk 
sempre que um novo bloco é necessário. A Figura 5-41 
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Pontos de entrada 



Figura 5-40 Alguns procedimentos envolvidos na leitura de um arquivo. 


mostra seis etapas sucessivas do crescimento de um arqui¬ 
vo seqüencial. 0 tamanho de bloco é de 1K e o tamanho de 
zona é de 2K nesse exemplo. 

Da primeira vez que newjblock é chamado, ele aloca a 
zona 12 (blocos 24 e 25). Da próxima vez, ele utiliza o 


bloco 25, que já foi alocado, mas não está ainda em utili¬ 
zação. Na terceira chamada, a zona 20 (blocos 40 e 41) é 
alocada e assim por diante. Zero_block (linha 24243) limpa 
um bloco, apagando seu conteúdo anterior. Essa descrição 
é consideravelmente mais longa do que o código real. 
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Figura 5-41 (a)-(f) Alocação sucessiva de blocos de 1K com uma zona de 2K. 
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Canalizações (Pipe) 

As canalizações são semelhantes a arquivos comuns sob 
muitos aspectos. Nessa seção, focalizaremos as diferenças. 

0 código que discutiremos está todo em pipe.c 

Antes de tudo, as canalizações são criadas de maneiras 
diferentes, pela chamada PIPE, em vez da chamada CREAT. 

A chamada PIPE é tratada por do_pipe (linha 24332). Tudo 
que do_pipe realmente faz é alocar um nó-i para a canali¬ 
zação e retornar dois descritores de arquivo para ele. As 
canalizações são possuídas pelo sistema, não pelo usuário, 
e estão localizadas no dispositivo de canalização designa¬ 
do (configurado em inclu.de/ minix/conjig.tí) , que pode¬ 
ria muito bem ser um disco de RAM, uma vez que dados de 
uma canalização não precisam ser conservados permanen¬ 
temente. 

Ler e gravar uma canalização é ligeiramente diferente 
de ler e gravar um arquivo, porque um pipe tem uma ca¬ 
pacidade finita. Uma tentativa de gravar em uma canali¬ 
zação que já está cheia fará com que o gravador seja sus¬ 
penso. De maneira semelhante, a leitura de uma canaliza¬ 
ção vazia suspenderá o leitor. Com efeito, uma canaliza¬ 
ção tem dois ponteiros, a posição atual (utilizado por lei¬ 
tores) e o tamanho (utilizado por escritores), para deter¬ 
minar a origem e o destino dos dados. 

As diversas verificações para ver se uma operação em 
uma canalização é possível são executadas por pipe_check 
(linha 24385). Além dos testes anteriores, que podem levar 
o chamador a ser suspenso, pipe_check chama release para 
ver se um processo previamente suspenso, devido a nenhum 
dado ou a dados demais, agora pode ser reanimado. Essas 
reanimações são feitas nas linhas 24413 a 24452, para es¬ 
critores e leitores que estão dormindo, respectivamente. A 
gravação em uma canalização quebrada (nenhum leitor) 
também é detectada aqui. 

0 ato de suspender um processo é feito por suspend (li¬ 
nha 24463). Tudo que ele faz é salvar os parâmetros da 
chamada na tabela de processos e configurar o sinalizador 
dontjreply como TRUE, inibindo a mensagem de resposta 
do sistema de arquivos. 

0 procedimento release (linha 24490) é chamado para 
verificar se um processo que foi suspenso em uma canali¬ 
zação pode agora ter permissão para continuar. Se encon¬ 
trar um, ele chama revive para configurar um sinalizador 
de modo que o laço principal o note mais tarde. Essa fun¬ 
ção não é uma chamada de sistema, mas é listada na Fi¬ 
gura 5-27(c), utilizando o mecanismo de passagem de 
mensagem. 

0 último procedimento em pipe.c é dojmpause (li¬ 
nha 2456o). Quando 0 gerenciador de memória está ten¬ 
tando sinalizar um processo, ele deve saber se esse processo 
está pendurado em uma canalização ou em um arquivo 
especial (caso em que deve ser acordado com um erro EÍN- 
TR). Uma vez que 0 gerenciador de memória não sabe nada 
sobre canalizações nem sobre arquivos especiais, ele envia 
uma mensagem para 0 sistema de arquivos para solicitar. 
Essa mensagem é processada por do_unpause, que reani¬ 


ma 0 processo se ele estiver bloqueado. Como revive, 
dojunpause tem alguma semelhança com uma chama¬ 
da de sistema, embora não seja uma. 

5.7.5 Diretórios e Caminhos 

Agora terminamos de ver como arquivos são lidos e gra¬ 
vados. Nossa próxima tarefa é ver como nomes de cami¬ 
nho e diretórios são tratados. 

Convertendo um Caminho em um Nó-i 

Muitas chamadas de sistema (p. ex„ OPEN, unlink e 
MOUNT) têm nomes de caminho (i. e., nomes de arquivo) 
como parâmetro. A maioria dessas chamadas deve buscar 
0 nó-i para 0 arquivo nomeado antes de poderem começar 
a trabalhar na própria chamada. A maneira como um nome 
de caminho é convertido em um nó-i é um assunto que 
agora veremos detalhadamente. Já vimos um esboço geral 
na Figura 5-14. 

A análise sintática de nomes de caminho é feita no ar¬ 
quivo path.c. 0 primeiro procedimento, eatj>ath (linha 
24727), aceita um ponteiro para um nome de caminho, 
analisa-o sintaticamente, arranja para seu nó-i ser carre¬ 
gado na memória e retorna um ponteiro para 0 nó-i. Ele 
faz seu trabalho chamando last_dir para obter 0 nó-i para 
0 diretório final e, então, chama advance para obter 0 com¬ 
ponente final do caminho. Se a pesquisa falhar, por exem¬ 
plo, porque um dos diretórios ao longo do caminho não 
existe, ou existe, mas está protegido contra pesquisa, 
NILJNODE é retornado em vez de um ponteiro para 0 nó- 
i. 

Os nomes de caminho podem ser absolutos ou relativos 
e podem ter muitos componentes arbitrariamente separa¬ 
dos por barras. Essas questões são tratadas por last_dir (li¬ 
nha 24754). Este último começa (linha 24771) examinan¬ 
do 0 primeiro caractere do nome de caminho para ver se é 
um caminho absoluto ou relativo. Para caminhos absolu¬ 
tos, rip é configurado para apontar para 0 nó-i raiz; para 
relativos, é configurado para apontar para 0 nó-i do dire¬ 
tório de trabalho atual. 

Nesse ponto, last_dir tem 0 nome de caminho e um 
ponteiro para 0 nó-i do diretório em que pesquisar 0 pri¬ 
meiro componente. Ele entra em um laço na linha 24782 
agora, analisa sintaticamente 0 nome de caminho, com¬ 
ponente por componente. Quando chega ao fim, retorna 
um ponteiro para 0 diretório final. 

Get_name (linha 24813) é um procedimento utili¬ 
tário que extrai componentes de cadeias de caracteres 
(strings ). Mais interessante é advance (linha 24855), que 
toma como parâmetros um ponteiro de diretório e uma 
cadeia e pesquisa a cadeia no diretório. Se localizar a string, 
advance retoma um ponteiro para seu nó-i. Os detalhes 
da transferência por intermédio do sistema de arquivos 
montados são tratados aqui. 

Embora advance controle a pesquisa de string, a com¬ 
paração real da string contra as entradas de diretório é fei- 
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ta em search_dir (linha 24936), que é o único lugar no 
sistema de arquivos onde arquivos de diretório realmente 
são examinados. Ele contém dois laços aninhados, um so¬ 
bre os blocos em um diretório e outro sobre as entradas em 
um bloco. Search_dir também é utilizado para entrar e 
para excluir nomes de diretórios. A Figura 5-42 mostra os 
relacionamentos entre alguns procedimentos importantes 
utilizados ao pesquisar nomes de caminho. 

Montando Sistemas de Arquivos 

Duas chamadas de sistema que afetam o sistema de 
arquivos como um todo, MOUNT e umouxt, permitem que 
sistemas de arquivos independentes em dispositivos secun¬ 
dários diferentes “fiquem colados”, formando uma única 
árvore de nomes transparente. A montagem, como vimos 
na Figura 5-32, é efetivamente alcançada lendo o nó-i raiz 
e o superbloco do sistema de arquivos a ser montado e con¬ 
figurando dois ponteiros em seu superbloco. Um deles apon¬ 
ta para o nó-i montado e o outro aponta para o nó-i da 
raiz do sistema de arquivos montado. Esses ponteiros co¬ 
nectam os sistemas de arquivos entre si. 

A configuração desses ponteiros é feita no arquivo 
mount.cçoxdo_mountVL?& linhas 25231 e 25232. As duas 
páginas de código que precedem a configuração dos pon¬ 
teiros são quase inteiramente dedicadas a verificar todos os 
erros que podem ocorrer na montagem de um sistema de 
arquivos, entre eles: 

1. O arquivo especial dado não é um dispositivo de 
blocos. 

2. 0 arquivo especial é um dispositivo de blocos, mas 
já está montado. 

3. 0 sistema de arquivos a ser montado tem um nú¬ 
mero mágico podre. 

4. 0 sistema de arquivos a ser montado é inválido (p. 
ex., nenhum nó-i). 


5. 0 arquivo a ser montado não existe ou é um ar¬ 
quivo especial. 

6. Não há espaço para os mapas de bits do sistema de 
arquivos montado. 

7. Não há espaço para o superbloco do sistema de 
arquivos montado. 

8. Não há espaço para o nó-i raiz do sistema de ar¬ 
quivos montado. 

Talvez pareça impróprio continuar tocando harpa nesse 
ponto, mas a realidade de qualquer sistema operacional 
prático é que uma fração substancial do código é dedicada 
a fazer tarefas menores que não são intelectualmente muito 
estimulantes, mas são cruciais para tomar um sistema uti¬ 
lizável. Se um usuário tentar montar o disquete errado aci¬ 
dentalmente, digamos, uma vez por mês e isso levar a uma 
queda e a um sistema de arquivos corrompido, o usuário 
irá considerar o sistema como instável e culpará o projetis¬ 
ta, não a si próprio. 

Thomas Edison uma vez fez uma observação que é re¬ 
levante aqui. Ele disse que “gênio” é 1% inspiração e 99% 
transpiração. A diferença entre um bom sistema e um sis¬ 
tema medíocre não é o brilho do algoritmo de agendamento 
do primeiro, mas sua atenção em fazer os detalhes funcio¬ 
narem direito. 

Desmontar um sistema de arquivos é mais fácil do que 
montar — há menos coisas que podem dar errado. 
Do_umount (linha 25241) trata disso. A única questão 
real é certificar-se de que nenhum processo tem qualquer 
arquivo ou diretório de trabalho abertos no sistema de ar¬ 
quivos a ser removido. Essa verificação é simples e direta: 
simplesmente varrer a tabela inteira de nós-i para ver se 
qualquer nó-i na memória pertence ao sistema de arqui¬ 
vos a ser removido (outro que não o nó-i raiz). Se encon¬ 
trar um, a chamada umount falha. 

0 último procedimento em mount.c é nameJo_dev 
(linha 25299). que pega um nome de caminho de arquivo 



de disco 
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Figura 5-42 Alguns procedimentos utilizados na pesquisa de nomes de caminho. 
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especial, obtém seu nó-i e extrai seus números de dispositi¬ 
vo primário e secundário. Esses últimos são armazenados 
no próprio nó-i, no lugar onde a primeira zona normal¬ 
mente entraria. Essa entrada está disponível porque os ar¬ 
quivos especiais não têm zonas. 

Vinculando e Desvinculando Arquivos 

O próximo arquivo a considerar é link.c. que lida com 
a vinculação e com a desvinculação de arquivos. 0 proce¬ 
dimento dojink (linha 25434) é muito parecido com 
do_mount sob o aspecto de que quase todo o código é de¬ 
dicado à verificação de erros. Alguns possíveis erros que 
podem ocorrer na chamada 

link{file_name, link_name)\ 

são listados a seguir: 

1. File_name não existe ou não pode ser acessado. 

2. File_name já tem o número máximo de vínculos. 

3. File__name é um diretório (somente o superusuá- 
rio pode criar vínculos para ele). 

4. Link_name já existe. 

5. Filejtiame e link_name estão em dispositivos di¬ 
ferentes. 

Se nenhum erro estiver presente, uma nova entrada de di¬ 
retório é feita com a string link_name e o número de nó- 
i de file_name. No código, namel corresponde a file_name 
e name2 corresponde a link_name. A entrada real é feita 
por search_dir, chamado de dojink na linha 25485. 

Arquivos e diretórios são removidos quando desvincu¬ 
lados. O trabalho das chamadas de sistema unlink e R.MDIR 
é feito por do_unlmk (linha 25504). Novamente, diversas 
verificações devem ser feitas; o teste de ver se um arquivo 
existe e o teste de ver se um diretório não é um ponto de 
montagem são feitos pelo código comum em dojunlink 
e, então, remove_dir ou unlink_ file é chamado, depen¬ 
dendo da chamada de sistema que está sendo suportada, o 
que será discutido em breve. 

A outra chamada de sistema suportada em link.c é Rt> 
Name. Os usuários de UNIX conhecem o comando de shell 
mv que, em última instância, utiliza essa chamada; seu 
nome reflete outro aspecto da chamada. Não apenas ela 
pode alterar o nome de um arquivo dentro de um diretório, 
como também efetivamente pode mover o arquivo de um 
diretório para outro, e essa chamada pode fazer isso ato¬ 
micamente, o que previne certas condições de corrida. O 
trabalho é feito por do_rename (linha 25563). Há muitas 
condições que devem ser testadas antes que esse comando 
possa ser completado, entre as quais estão: 

1. O arquivo original deve existir (linha 25578). 

2. O nome de caminho antigo não deve ser um nome 
de caminho acima do novo diretório na árvore de 
diretórios (linhas 25596 a 25613). 

3. Nem nem são aceitáveis como um nome 
antigo ou novo (linhas 25618 e 25619) ■ 


4. Os dois diretórios-pai devem estar no mesmo dis¬ 
positivo (linha 25622). 

5. Os dois diretórios-pai devem ser graváveis, pesqui¬ 
sáveis e estar em um dispositivo gravável (linhas 
25625e25626). 

6. Nem 0 nome antigo nem 0 novo podem ser um 
diretório com um sistema de arquivos montado por 
cima. 

Há algumas outras condições que devem ser verificadas se 
0 novo nome já existir, mas a principal é que deve ser pos¬ 
sível remover 0 arquivo existente com 0 novo nome. 

No código para do_rename, há alguns exemplos de 
decisões de projeto que foram tomadas para minimizar a 
possibilidade de certos problemas. Renomear um arquivo 
para um nome que já existe poderia resultar em um disco 
cheio, mesmo que esse não fosse 0 caso, se 0 arquivo antigo 
não for removido primeiro, e é isso que é feito, nas linhas 
2566 O a 25666. A mesma lógica é utilizada na linha 25680: 
remover 0 nome antigo de arquivo antes de criar um novo 
nome no mesmo diretório, para evitar a possibilidade de 0 
diretório precisar adquirir um bloco adicional. Entretanto, 
se fosse 0 caso de 0 novo arquivo e de 0 arquivo antigo esta¬ 
rem em diretórios diferentes, essa preocupação não seria 
relevante, e na linha 25685 um novo nome de arquivo é 
criado (em um diretório diferente) antes de 0 antigo ser 
removido, porque de um ponto de vista da integridade de 
sistema uma queda que deixasse dois nomes de arquivo 
apontando para um nó-i seria muito menos séria que uma 
queda que deixasse um nó-i não sendo apontado por ne¬ 
nhuma entrada de diretório. A probabilidade de esgotamento 
do espaço durante uma operação de renomear é baixa, e a 
de uma queda de sistema mais baixa ainda, mas nesses ca¬ 
sos não custa muito estar preparado para 0 pior caso. 

As demais funções em link.c suportam as que já discu¬ 
timos. Para complementar, a primeira delas, truncate (li¬ 
nha 25717), é chamada de várias outras posições no siste¬ 
ma de arquivos. Ela passa por um nó-i uma zona por vez, 
liberando todas as zonas que encontra, assim como os blo¬ 
cos indiretos. Remove_dir (linha 25777) executa alguns 
testes adicionais para assegurar que 0 diretório pode ser 
removido e, então, chama unlink J.ile (linha 25818). Se 
nenhum erro for encontrado, a entrada de diretório é lim¬ 
pa, e a contagem de vínculos no nó-i é diminuída de um. 

5.7.6 Outras Chamadas de Sistema 

O último grupo de chamadas de sistema é uma mistu¬ 
ra de coisas envolvendo status, diretórios, proteção, tempo 
e outros serviços. 

Alterando o Status de Diretórios e de 
Arquivos 

O arquivo stadir.c contém 0 código para quatro cha¬ 
madas de sistema: CHDIR, CHROOT, STAT e FSTAT. Ao estudar 
last_dir vimos como pesquisas de caminho iniciam olhan- 
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do no primeiro caractere do caminho, para ver se é uma 
barra ou não. Dependendo do resultado, um ponteiro, en¬ 
tão, é configurado como o diretório de trabalho ou como o 
diretório-raiz. 

A alteração de um diretório de trabalho (ou diretório- 
raiz) para outro é uma simples questão de alterar esses dois 
ponteiros dentro da tabela de processos do chamador. Es¬ 
sas alterações são feitas por do_chdir (linha 25924) e por 
do_chroot (linha 25963). Essas duas fazem a verificação 
necessária e, então, chamam change (linha 25978) para 
abrir o novo diretório e substituir o antigo. 

Em do_chdir, o código nas linhas 25935 a 25951 nãoé 
executado em chamadas CHDIR feitas por processos de usu¬ 
ário. Ele é feito especificamente para chamadas do geren¬ 
ciador de memória, a fim de alternar para um diretório do 
usuário com o propósito de tratar as chamadas F.XEC. Quan¬ 
do um usuário tenta executar um arquivo, digamos, a.out 
em seu diretório de trabalho, é mais fácil para o gerencia¬ 
dor de memória mudar para esse diretório que tentar des¬ 
cobrir onde está. 

As duas chamadas de sistema restantes tratadas nesse 
arquivo, STAT e FSTAT, são basicamente as mesmas, exceto 
por como o arquivo é especificado. A primeira fornece um 
nome de caminho, enquanto a última oferece o descritor 
de arquivo de um arquivo aberto. Os dois procedimentos 
de primeiro nível, do_stat (linha 26014) e do Jstat (linha 
26035), chamam statjnode para fazer 0 trabalho. Antes 
de chamar stat_inode, do_stat abre 0 arquivo para obter 
seu nó-i. Dessa maneira, tanto do_stat como do^Jstatpas- 
sam um ponteiro de nó-i para statjnode. 

Tudo qu ç. statjnode (linha 26051) faz é extrair as in¬ 
formações do nó-i e copiar para um buffer, 0 qual explici¬ 
tamente deve ser copiado para 0 espaço do usuário cha¬ 
mando sys_copy na linha 26088 porque é muito grande 
para caber em uma mensagem. 

Proteção 

0 mecanismo de proteção do mintx utiliza os bits rwx. 
Três conjuntos de bits estão presentes para cada arquivo: 
para 0 proprietário, para seu grupo e para outros. Os bits 
são configurados pela chamada de sistema CHMOD, que é 
executada por do_chmod no arquivo protect.c (linha 
26124). Depois de fazer uma série de verificações de vali¬ 
dade, 0 modo é alterado na linha 26150. 


A chamada de sistema chown é semelhante a CHMOD 
no sentido de que ambas alteram um campo interno de 
nó-i em algum arquivo. A implementação também é se¬ 
melhante embora do_chown (linha 26l63) possa ser uti¬ 
lizada de modo que 0 proprietário seja alterado somente 
pelo superusuário. Usuários comuns podem utilizar essa 
chamada para alterar 0 grupo de seus próprios arquivos. 

A chamada de sistema cmask permite que 0 usuário 
configure uma máscara (armazenada na tabela de pro¬ 
cessos), que, então, mascara bits em chamadas de sistema 
CREAT subseqüentes. A implementação completa seria so¬ 
mente uma declaração, na linha 26209 , exceto que a cha¬ 
mada deve retornar 0 valor antigo de máscara como seu 
resultado. Esse fardo adicional triplicou 0 número de li¬ 
nhas de código exigido (linhas 26208 a 26210 ). 

A chamada de sistema ACCESS torna possível para um 
processo saber se pode acessar um arquivo de uma manei¬ 
ra especificada (p. ex., para leitura). Ela é implementada 
por do_access (linha 26217), que busca 0 nó-i do arquivo 
e chama 0 procedimento interno, forbidden (linha 26242), 
para ver se 0 acesso é proibido. Forbidden verifica 0 uid e 
0 gid. assim como as informações no nó-i. Dependendo do 
que encontra, seleciona um dos três grupos rwx e verifica 
se 0 acesso é permitido ou proibido. 

Read_only (linha 26304) é um procedimento interno 
pequeno que diz se 0 sistema de arquivos em que 0 nó-i 
passado como parâmetro está montado somente para lei¬ 
tura ou para gravação. É necessário impedir gravações em 
sistemas de arquivos montados somente para leitura. 

Tempo 

O MiNix tem várias chamadas de sistema que envolvem 
tempo: UTIME, TIME, STIME e TIMES. Estão resumidas na Fi¬ 
gura 5-43. Embora a maioria delas não tenha nada a ver 
com arquivos, faz sentido incluí-las no sistema de arqui¬ 
vos porque as informações de tempo são registradas em 
um nó-i do arquivo. 

Associado com cada arquivo estão três números de 32 
bits. Dois desses registram os tempos do último acesso e da 
última modificação do arquivo. O terceiro registra quando 
0 status do próprio nó-i foi por último alterado. Esse tem¬ 
po irá mudar para quase todos os acessos a um arquivo, 
exceto um read ou um KXKC. Esses tempos são mantidos 
no nó-i. Com a chamada de sistema utime, os tempos de 


Chamada 

Função 

UTIME 

Configura 0 tempo da última modificação do arquivo 

TIME 

Configura 0 tempo real atual em segundos 

STIME 

Configura 0 relógio de tempo real 

TIMES 

Obtém os tempos de contabilidade de processo 


Figura 5-43 As quatro chamadas de sistema envolvendo tempo. 
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acesso e de modificação podem ser configurados pelo pro¬ 
prietário do arquivo ou pelo superusuário. 0 procedimen¬ 
to do_utime (linha 26422) no arquivo time.c executa a 
chamada de sistema, buscando o nó-i e armazenando o 
tempo nele. Na linha 26450, os sinalizadores indicando 
que uma atualização de tempo é necessária são redefini¬ 
dos, então, o sistema não fará uma cara e redundante cha¬ 
mada a dockjime. 

O tempo real não é mantido pelo sistema de arquivos. 
Ele é mantido pela tarefa de relógio dentro do kernel. Con¬ 
sequentemente, a única maneira de obter ou de configurar 
o tempo real é enviar uma mensagem à tarefa de relógio. 
Isso é, de fato, o que fazem dojime e do_stime. O tempo 
real está em segundos, desde I o de janeiro de 1970. 

As informações de contabilidade também são mantidas 
pelo kernel. A cada tique de relógio, ele cobra um tique de 
algum processo. Essas informações podem ser recuperadas 
enviando uma mensagem à tarefa de sistema, que é o que 
dojims (linha 26492) faz. O procedimento não é nomea¬ 
do dojimes porque a maioria dos compiladores C adicio¬ 
na um sublinhado à frente de todos símbolos externos, e a 
maioria dos linkeditors trunca símbolos para oito caracte¬ 
res, o que tornaria dojime indistinguível de dojimes. 

Sobras 

O arquivo misc.c contém procedimentos para algumas 
chamadas de sistema que não se ajustam em nenhum ou¬ 
tro lugar. A chamada de sistema DUP duplica um descritor 
de arquivo. Em outras palavras, ela cria um novo descritor 
de arquivo que aponta para o mesmo arquivo que seu ar¬ 
gumento. A chamada tem uma variante DUP2. Ambas as 
versões da chamada são tratadas por do_dup (linha 26632). 
Essa função é incluída no MINIX para suportar programas 
binários antigos. Essas duas chamadas estão obsoletas. A 
versão atual da biblioteca C do minix invocará a chamada 
de sistema FCNTL quando qualquer uma dessas for encon¬ 
trada em um arquivo fonte em C. 

FCNTL, tratada por do Jcntl (linha 26670) é a maneira 
preferida de solicitar operações em um arquivo aberto. Os 
serviços são solicitados utilizando sinalizadores definidos 


pelo POSix, descritos na Figura 5-44. A chamada é invoca¬ 
da com um descritor de arquivo, com um código de solici¬ 
tação e com argumentos adicionais conforme necessário 
para a solicitação em particular. Por exemplo, o equiva¬ 
lente da antiga chamada 

dup2(fd, fd2); 

seria 

fcntl(fd, F_DUPFD, fd2); 

Várias dessas solicitações configuram ou lêem um sinali¬ 
zador; o código consiste em somente algumas linhas. Por 
exemplo, a solicitação F_SETFD configura um bit que for¬ 
ça o fechamento de um arquivo quando o processo do seu 
proprietário faz um EXEC. A solicitação FjSETFD é utiliza¬ 
da para determinar se um arquivo deve ser fechado quan¬ 
do uma chamada EXEC é feita. As solicitações FJSETFL e 
F_GETFL permitem configurar sinalizadores para indicar 
que um arquivo particular está disponível no modo não- 
bloqueador ou para operações append. 

Do Jcntl também lida com gerenciamento de bloqueio. 
Uma chamada com o comando F_GETLK , F_SETLK ou 
FJETLVW especificada é traduzida em uma chamada a 
lockjop, discutida em uma seção anterior. 

A próxima chamada de sistema é SYNC, que copia de 
volta para o disco todos os blocos e os nós-i que foram mo¬ 
dificados desde que foram carregados. A chamada é pro¬ 
cessada por do_sync (linha 26730). Ela simplesmente pes¬ 
quisa por todas as tabelas, pesquisando entradas sujas. Os 
nós-i devem ser processados primeiro, uma vez que 
rwjnode deixa seus resultados no cache de blocos. Afinal 
de contas, nós-i sujos são gravados no cache de blocos, en¬ 
tão, todos os blocos sujos são gravados no disco. 

As chamadas de sistema FORK, EXEC, exit e SET são, na 
realidade, chamadas do gerenciador de memória, mas os 
resultados devem ser colocados aqui também. Quando um 
processo bifurca, é essencial que o kernel, o gerenciador de 
memória e o sistema de arquivos saibam disso. Essas “cha¬ 
madas de sistema” não vêm de processos de usuário, mas 
do gerenciador de memória. Do jork, do_exit e do_set re¬ 
gistram as informações relevantes na parte do sistema de 


Operação 

Significado 

F_DUPFD 

Duplica um descritor de arquivo 

FJ3ETFD 

Obtém o sinalizador close-on-exec 

F_SETFD 

Configura o sinalizador close-on-exec 

F_GETFL 

Obtém sinalizadores de status de arquivo 

F_SETFL 

Configura sinalizadores de status de arquivo 

FJ3ETLK 

Obtém status de bloqueio de um arquivo 

F_SETLK 

Configura bloqueio de leitura/gravação em um arquivo 

F_SETLKW 

Configura bloqueio de gravação em um arquivo 


Figura 5-44 O POSIX exige parâmetros para a chamada de sistema FCNTL. 
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arquivos da tabela de processo. Do_exec pesquisa e fecha 
(utilizando do_dose) qualquer arquivo marcado para ser 
fechado ao executar (çlose-on-exec). 

A última função nesse arquivo não é realmente uma 
chamada de sistema, mas é tratada como tal. Trata-se de 
do_revive (linha 26921), que é chamada quando uma ta¬ 
refa que era previamente incapaz de completar o trabalho 
que o sistema de arquivos tinha solicitado, como oferecer 
dados de entrada para um processo de usuário, agora com¬ 
pletou o trabalho. O sistema de arquivos, então, reanima o 
processo e envia a mensagem de resposta. 

5.7.7 Interface de Dispositivos de E/S 

A E/S no MINIX é feita enviando mensagens às tarefas 
dentro do kernel. A interface do sistema de arquivos com 
essas tarefas está contida no arquivo device.c. Quando E/S 
real de dispositivo é necessária, devjo (linha 27033) é 
chamada a partir de read_write para tratar arquivos espe¬ 
ciais de caractere e de rw_block para arquivos especiais de 
bloco. Ela constrói uma mensagem-padrão (veja Figura 
3-15) e envia para a tarefa especificada. As tarefas são cha¬ 
madas pela linha 

(*dmap[major].dmap-rw)(task, &dev_mess); 

(linha 27056). Essa chamada funciona via ponteiros na 
matriz dmap definida em table.c. As funções que cuidam 
disso estão todas em device.c. Enquanto dev_io está espe¬ 
rando uma resposta da tarefa, o sistema de arquivos espe¬ 
ra. Ele não tem multiprogramação interna. Normalmente, 
contudo, essas esperas são bastante curtas (p. ex., 50ms). 

Arquivos especiais podem necessitar de processamento 
especial quando são abertos ou fechados. O que deve ser 
feito exatamente depende do tipo de dispositivo. A tabela 
dmap tambeTn é utilizada para determinar quais funções 
são indicadas para abrir e fechar cada tipo de dispositivo 
principal. O procedimento devjopcl (linha 27071) é cha¬ 
mado para dispositivos de disco, sejam disquetes, discos rí¬ 
gidos ou dispositivos baseados em memória. A linha 

mess_ptr->PROC_NR = fp - fproc; 

(linha 27081) calcula o número de processo do chamador. 
0 trabalho real é feito passando o número da tarefa e um 
ponteiro para mensagem a calljask, que discutiremos a 
seguir. Dev_opcl também é utilizado para fechar os mes¬ 
mos dispositivos. De fato, a única diferença entre as fun¬ 
ções de abrir e fechar no nível dessa função está no que 
acontece depois do retorno de call_task. 

Outras funções chamadas via estrutura dmap incluem 
tty_open e tty_close. que servem as linhas seriais e 
ctty_open e cttyjdose que servem o console. O último des¬ 
tes, dty_close , é particularmente uma rotina fictícia, uma 
vez que tudo que faz é retornar o status de OK incondicio¬ 
nalmente. 

A chamada de sistema SETSID requer algum trabalho 
por parte do sistema de arquivos e isso é realizado por 
do_setsid (linha 27164). Uma chamada de sistema. IOCTI., 


é tratada principalmente em device.c. Essa chamada foi 
colocada aqui porque está intimamente relacionada com 
a interface de tarefas. Quando uma IOCTI, é feita, dojoctl é 
chamado para construir uma mensagem e enviar para a 
tarefa adequada. 

Para controlar dispositivos de terminal, uma das fun¬ 
ções declaradas em include/ ter mios.h deve ser utilizada 
em programas escritos para serem compatíveis com POSIX. 
A biblioteca C traduzirá tais funções em chamadas IOCTI. 
Para outros dispositivos que não terminais, IOCTL é utiliza¬ 
da para muitas operações, muitas das quais foram descri¬ 
tas no Capítulo 3- 

A próxima função é a única função PRWATE nesse ar¬ 
quivo. Trata-se de find_dev (linha 27228), um pequeno 
procedimento auxiliar que extrai os números de dispositi¬ 
vo primário e secundário de um número de dispositivo com¬ 
pleto. 

A leitura e a gravação reais da maioria dos dispositivos 
passa por calljask (linha 27245), que dirige uma mensa¬ 
gem à tarefa apropriada na imagem do kernel, chamando 
sendrec. A tentativa pode falhar se a tarefa estiver tentando 
reanimar um processo em resposta a uma solicitação an¬ 
terior. Provavelmente seria um processo diferente daquele 
em favor do qual a solicitação atual está sendo feita. 
Calljask exibirá uma mensagem no console se uma men¬ 
sagem imprópria for recebida. Essas mensagens não serão 
vistas, esperamos, durante a operação normal do MINIX, 
mas poderiam aparecer durante tentativas de desenvolver 
um novo driver de dispositivo. 

O dispositivo/dev/tl)’ fisicamente não existe. É uma fic¬ 
ção a que qualquer usuário de sistema multiusuário pode 
referir-se, sem precisar determinar quais de todos os possí¬ 
veis terminais reais estão em utilização. Quando uma men¬ 
sagem que referencia/zfoy/Q’ deve ser enviada, a próxima 
função, calljdty (linha 27311), localiza os dispositivos 
primário e secundário corretos e substitui-os na mensa¬ 
gem antes de passar a mensagem via calljask. 

Por fim, a última função no arquivo é no_dev (linha 
27337), que é chamada para entradas na tabela para as 
quais um dispositivo não existe, por exemplo, quando um 
dispositivo de rede é referenciado em uma máquina sem 
suporte de rede. Ela retorna um status ENODEV. Isso previ¬ 
ne quedas quando dispositivos inexistentes são acessados. 

5.7.8 Utilitários Gerais 

O sistema de arquivos contém alguns procedimentos 
utilitários de propósito geral que são utilizados em vários 
lugares. Eles estão agrupados no arquivo utility.c. 

O primeiro procedimento é clockjime (linha 27428). 
Ele envia mensagens à tarefa de relógio para saber qual é o 
tempo real atual. O próximo procedimento, fetch_name 
(linha 27447), é necessário porque muitas chamadas de 
sistema têm um nome de arquivo como parâmetro. Se o 
nome de arquivo for curto, ele será incluído na mensagem 
do usuário para o sistema de arquivos. Se for longo, um 
ponteiro para o nome em espaço do usuário será colocado 
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na mensagem. Fetch_name verifica ambos os casos e, de 
qualquer maneira, obtém o nome. 

Duas funções aqui tratam classes gerais de erros. No_sys 
é o manipulador de erro que é chamado quando o sistema 
de arquivos recebe uma chamada de sistema que não é 
uma de suas chamadas. Panic imprime uma mensagem e 
diz ao kernel para jogar a toalha quando algo catastrófico 
acontece. 

As últimas duas funções. conv2 e conv4, existem para 
ajudar o minix a lidar com o problema de diferentes ordens 
de byte em processadores Intel e Motorola. Essas rotinas 
são chamadas durante a leitura ou a gravação para uma 
estrutura de dados em disco, como um nó-i ou como um 
mapa de bits. A ordem de byte no sistema que criou o disco 
é registrada no superbloco. Se é diferente da ordem utiliza¬ 
da pelo processador local, a ordem será trocada. O restante 
do sistema de arquivos não precisa saber nada sobre a or¬ 
dem de byte no disco. 

O último arquivo éputk.c. Ele contém dois procedimen¬ 
tos, ambos tendo a ver com a impressão de mensagens. Os 
procedimentos padrão de biblioteca não podem ser utiliza¬ 
dos, porque enviam mensagens para o sistema de arqui¬ 
vos. Esses procedimentos enviam mensagens diretamente 
para a tarefa de terminal. Vimos um par de funções quase 
idêntico na versão do gerenciador de memória desse ar¬ 
quivo. 

5.8 RESUMO 

Quando visto de fora, um sistema de arquivos é uma 
coleção de arquivos e de diretórios, mais as operações so¬ 
bre os mesmos. Os arquivos podem ser lidos e gravados, os 
diretórios podem ser criados e destruídos, e os arquivos po¬ 


E X E R C 

1. Forneça cinco nomes diferentes de caminho para o arquivo 
/etc/passwd. (Sugestão: pense nas entradas de diretório 

e 

2. Os sistemas que suportam arquivos sequenciais sempre têm 
uma operação para retroceder arquivos. Sistemas que su¬ 
portam acesso aleatório a arquivos precisam disso também? 

3. Alguns sistemas operacionais oferecem uma chamada de 
sistema RENAME para dar um novo nome a um arquivo. Há 
qualquer diferença entre utilizar essa chamada para reno- 
mear um arquivo e simplesmente copiar o arquivo para um 
novo arquivo com o novo nome, seguido da exclusão do 
antigo? 

4. Considere a árvore de diretórios da Figura 5-7. S t/usr/jim é 
o diretório de trabalho, qual é o nome de caminho absoluto 
para o arquivo cujo nome de caminho relativo é.Jast/xí 


dem ser movidos de um diretório para outro. Sistemas de 
arquivos mais modernos suportam um sistema de diretóri¬ 
os hierárquico, nos quais diretórios podem ter subdiretóri- 
os ad infínitum. 

Quando visto do interior, um sistema de arquivos pare¬ 
ce bem diferente. Os projetistas de sistema de arquivos pre¬ 
cisam preocupar-se com o modo como o armazenamento 
é alocado e com o modo como o sistema monitora qual 
bloco que vai com qual arquivo. Também vimos como di¬ 
ferentes sistemas têm diferentes estruturas de diretórios. A 
confiabilidade e o desempenho do sistema de arquivos tam¬ 
bém são questões importantes. 

A segurança e a proteção são de interesse vital tanto 
para os usuários do sistema como para projetistas. Discuti¬ 
mos algumas falhas de segurança em outros sistemas e 
problemas genéricos que muitos sistemas têm. Também 
vimos autenticação, com e sem senhas, listas de controle 
de acesso e capacitações, assim como um modelo de ma¬ 
triz para pensar sobre a proteção. 

Por fim. estudamos o sistema de arquivos do minix de¬ 
talhadamente. Ele é grande, mas não muito complicado. 
Ele aceita solicitações de trabalho de processos de usuário, 
pesquisa em uma tabela de ponteiros de procedimentos e 
chama o procedimento para executar a chamada de siste¬ 
ma solicitada. Devido à sua estrutura modular e à posição 
fora do kernel, ele pode ser removido do MINIX e utilizado 
como um servidor de arquivos de rede independente com 
apenas pequenas modificações. 

Internamente. o MINIX bufferiza os dados em um ca¬ 
che de blocos e tenta fazer leitura antecipada ao fazer aces¬ 
so seqüencial a arquivo. Se o cache tiver sido feito grande o 
suficiente, a maior parte do texto do programa j á estará na 
memória durante operações que acessem repetidamente um 
conjunto particular de programas, como uma compilação. 


í C I O s 

5. A alocação contígua de arquivos leva à fragmentação de dis¬ 
co, como mencionado no texto. F.ssa fragmentação é inter¬ 
na ou externa? Faça uma analogia com algo discutido no 
capítulo anterior. 

6. Um sistema operacional somente suporta um único dire¬ 
tório. mas permite que o diretório tenha arbitrariamente 
muitos arquivos com nomes de arquivo arbitrariamente lon¬ 
gos. Pode-se simular algo próximo de um sistema de arqui¬ 
vos hierárquico? Como? 

7. O espaço livre em disco pode ser monitorado utilizando uma 
lista de blocos livres ou um mapa de bits. Os endereços de 
disco requerem D bits. Para um disco com B blocos. F dos 
quais estão livres, declare a condição sob qual a lista de li¬ 
vres utiliza menos espaço que o mapa de bits. Para D tendo 
o valor de 16 bits. expresse sua resposta como uma porcen¬ 
tagem do espaço em disco que deve estar livre. 
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8 . Foi sugerido que a primeira parte de cada arquivo Unix seja 
mantida no mesmo bloco de disco que seu nó-i. Que benefí¬ 
cio isso traria? 

9. O desempenho de um sistema de arquivos depende da taxa 
de acerto de cache (fração de blocos localizados no cache). 
Se leva lms para satisfazer uma solicitação do cache, mas 
40ms para satisfazer uma solicitação se uma leitura de dis¬ 
co é necessária, dê uma fórmula para o tempo médio exigi¬ 
do para satisfazer uma solicitação se a taxa de acerto é h. 
Represente graficamente essa função para valores de h de 0 
a 10. 

10. Um disquete tem 40 cilindros. Uma busca leva 6ms por ci¬ 
lindro movido. Se nenhuma tentativa for feita para colocar 
os blocos de um arquivo perto um do outro, dois blocos que 
são logicamente consecutivos (i. e„ um segue o outro no 
arquivo) terão aproximadamente 13 cilindros de distância 
entre si, na média. Se. entretanto, o sistema operacional fi¬ 
zer uma tentativa de agrupar os blocos relacionados, a dis¬ 
tância média entre blocos pode ser reduzida a dois cilindros 
(por exemplo). Quanto tempo leva para ler um arquivo de 
100 blocos em ambos os casos, se a latência rotacional é de 
lOOrns e o tempo de transferência é de 25ms por bloco? 

11. A compactação periódica do armazenamento de disco seria 
de qualquer valor concebível? Explique. 

12. Como o TENEX poderia ser modificado para evitar o proble¬ 
ma de senha descrito no texto? 

13. Depois de formar-se, você se candidata para um emprego 
como diretor de um grande CPD de uma universidade que 
acaba de jogar fora seu sistema operacional antigo e alter¬ 
nar para o UNIX. Você consegue o trabalho. Quinze minutos 
depois de começar a trabalhar, seu assistente entra em seu 
escritório e grita: "Alguns alunos descobriram o algoritmo 
que utilizamos para criptografar senhas e publicaram-no 
no BBS' 1 . O que você deve fazer? 

14. O esquema de proteção de Morris-Thompson com números 
aleatórios de n bits foi projetado para tornar difícil para um 
intruso descobrir um grande número de senhas por cripto¬ 
grafar strings comuns de antemão. Esse esquema também 
oferece proteção contra um aluno usuário que está tentan¬ 
do adivinhar a senha de superusuário na sua máquina? 

15. Um departamento de ciência da computação tem uma gran¬ 
de coleção de máquinas UNIX em sua rede local. Os usuários 
em qualquer máquina podem dar um comando da fornia 

machineã who 

e fazer com que ele seja executado em machine4. sem pre¬ 
cisar ter o usuário conectado na máquina remota. Esse re¬ 
curso é implementado fazendo o kernel do usuário enviar o 
comando e seu uid para a máquina remota. Esse esquema é 
seguro se os kernels são todos confiáveis (p. ex., minicom¬ 
putadores de tempo compartilhado de grande porte com har¬ 
dware de proteção)? E se algumas máquinas são computa¬ 
dores pessoais de alunos, sem hardware de proteção? 

16. Quando um arquivo é removido, seus blocos geralmente são 
devolvidos na lista de livres, mas eles não são apagados. Você 
acha que seria uma boa idéia ter o sistema operacional apa¬ 
gando cada bloco antes de liberá-lo? Considere tanto os fa¬ 
tores tanto segurança como desempenho em sua resposta e 
explique o efeito de cada um. 


17. Três mecanismos diferentes de proteção que discutimos são 
capacidades, listas de controle de acesso, e os bits rux do 
UNIX. Para cada um dos seguintes problemas de proteção, 
diga qual desses mecanismos pode ser utilizado. 

(a) Ken quer que seus arquivos possam ser lidos por todo 
mundo, exceto por seu companheiro de escritório. 

(b) Mitch e Steve querem compartilhar alguns arquivos 
secretos. 

(c) Linda quer que alguns dos seus arquivos sejam públi¬ 
cos. 

Para UNIX, suponha que os grupos são categorias como pro¬ 
fessores e funcionários, alunos, secretárias, etc. 

18. Considere o seguinte mecanismo de proteção. A cada objeto 
e a cada processo é atribuído um número. Um processo so¬ 
mente pode acessar um objeto se o objeto tiver um número 
mais alto que o processo. Com qual dos esquemas de arqui¬ 
vo discutidos no texto isso se assemelha 5 De que maneira 
essencial ele difere do esquema no texto? 

19. O cavalo de Tróia pode atacar o trabalho em um sistema 
protegido por capacidades? 

20. Dois alunos de ciência da computação, Carolyn e Elinor.es- 
tão tendo uma discussão sobre nós-i. Carolyn sustenta que 
as memórias ficaram tão grandes e tão baratas que quando 
um arquivo é aberto, é mais simples e mais rápido simples¬ 
mente colocar uma nova cópia do nó-i na tabela de nós-i, 
em vez de pesquisar a tabela inteira para ver se ele já está lá. 
Elinor discorda. Quem está certo? 

21. Qual é a diferença entre um vírus e um verme? Como cada 
um deles se reproduz? 

22. Vínculos simbólicos são arquivos que apontam para outros 
arquivos ou para outros diretórios indiretamente. Diferente¬ 
mente de vínculos comuns como aqueles atualmente im¬ 
plementados no MINIX, um vínculo simbólico tem seu pró¬ 
prio nó-i, que aponta para um bloco de dados. 0s bloco de 
dados contêm o caminho para o arquivo de destino do vín¬ 
culo, e o nó-i torna possível para o vínculo ter proprietários 
e permissões diferentes dos do arquivo de destino do víncu¬ 
lo. Um vínculo simbólico e o arquivo ou diretório para que 
ele aponta podem ser localizados em dispositivos diferentes. 
Vínculos simbólicos não são parte do padrão POSIX 1990, 
mas espera-se que sejam adicionados ao POSIX no futuro. 
Implemente vínculos simbólicos para o MINIX. 

23- Você descobre que o limite de tamanho de arquivo de 64MB 
no mintx não é suficiente para suas necessidades. Estenda o 
sistema de arquivos, utilizando o espaço não-utilizado no 
nó-i para um bloco indireto triplo. 

24. Mostre se configurar ROBUST torna o sistema de arquivos 
mais ou menos robusto em face de uma queda. Se esse é o 
caso, na versão atual do mintx ainda não foi explorado, por¬ 
tanto, pode ser qualquer um. Examine bem o que acontece 
quando um bloco modificado é expulso do cache. Leve em 
conta que blocos de dados modificados podem ser acompa¬ 
nhados por um nó-i e por um mapa de bits modificado. 

25. 0 tamanho da tabela filp atualmente está definido como uma 
constante, NR_FILPS, em fs/const.h. Para acomodar mais 
usuários em um sistema em rede, você quer aumentar 
NR_PROCS em include/minix/config.h . De que modo 
NR_FILPS deveria ser definido como uma função de 
NRJPROCS? 
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26. Projete um mecanismo para adicionar suporte a um siste¬ 
ma de arquivos “estrangeiro”, de modo que se poderia, por 
exemplo, montar um sistema de arquivos MS-DOS em um 
diretório no sistema de arquivos do minix. 


27. Suponha que um avanço tecnológico ocorra e que a RAM 
não-volátil, que mantém seu conteúdo confiável após uma 
queda de energia, torne-se disponível sem desvantagem de 
preço ou de desempenho sobre a RAM convencional. Quais 
aspectos do projeto do sistema de arquivos seriam afetados 
por esse desenvolvimento? 



6 


Lista de Leitura 
e Bibliografia 


Nos cinco capítulos anteriores, abordamos uma varie¬ 
dade de temas. Este capítulo foi concebido como uma aju¬ 
da a leitores interessados em se aprofundar no grande es¬ 
tudo de sistemas operacionais mais ainda. A seção 6.1 é 
uma lista de leituras sugeridas. A seção 6.2 é uma biblio¬ 
grafia alfabética de todos livros e artigos citados neste li¬ 
vro. 

Além das referências dadas a seguir, as Proceedings of 
the n-th ACM Symposium on Operating Systems Princi¬ 
pies (ACM) publicadas bianualmente e o Proceedings of 
the n-th International Conference on Distributed Com- 
puting Systems (IEEE) publicadas anualmente são bons 
lugares para procurar papers recentes sobre sistemas ope¬ 
racionais. Assim também é o Symposium on Operating 
Systems Design and Implementation da USENIX. Além 
disso, os periódicos da ACM Transactions on Computer Sys¬ 
tems e Operating Systems Review freqüen temente têm arti¬ 
gos relevantes. 


6.1 SUGESTÕES PARA LEITURAS 
SUPLEMENTARES 

6.1.1 Introdução e Trabalhos Gerais 

Brooks, The MythicalMan-Month: Essays on Software En- 
gineering 

Um livro informativo, divertido e engenhoso sobre como 
não escrever um sistema operacional, feito por alguém que 
aprendeu da maneira mais difícil. Repleto de bons conse¬ 
lhos. 


Comer, Operation System Design. TheXinu Approach 
Um livro sobre o sistema operacional Xinu, que roda 
no computador LSI-11. Contém uma detalhada exposição 
do código-fonte, incluindo uma listagem completa em C. 

Corbató. “On Building Systems That Will Fail" 

Esta é a conferência que recebeu o Prêmio Turing, o 
pai do compartilhamento de tempo aborda muitas das mes¬ 
mas preocupações que interessam a Brooks em The Mythi¬ 
cal Man-Month. Sua conclusão é que todos os sistemas 
complexos finalmente falharão e que, para ter qualquer 
chance para êxito, é absolutamente essencial evitar a com¬ 
plexidade e esforçar-se para utilizar a simplicidade e a ele¬ 
gância em um projeto. 

Deitei, Operating Systems, 2 a Ed. 

Um texto geral sobre sistemas operacionais. Além do 
material padrão, contém estudos de caso de UNIX, MS-DOS, 
MVS, VM, os/ 2 , e o sistema operacional do Macintosh. 

Finkel,h« Operating Systems Vade Mecum 

Outro texto geral sobre sistemas operacionais. É orien¬ 
tado para a prática, bem escrito e cobre muitos dos temas 
tratados neste livro, tornando-o um bom lugar para pro¬ 
curar uma perspectiva diferente sobre o mesmo assunto. 

IEEE .Information Technology—Portable Operating Sys¬ 
tem Interface (°OSix), Part I: System Application Program 
Interface (API) [CLanguage] 

Este é o padrão. Algumas partes são realmente bem le¬ 
gíveis, especialmente o Anexo B, “Rationale and Notes", 
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que freqüentemente joga uma luz sobre por que as coisas 
são feitas como são. Uma vantagem de consultar o docu¬ 
mento-padrão é que, por definição, não há nenhum erro. 
Se um erro tipográfico em um nome de macro passar pelo 
processo de edição não é mais um erro, é oficial. 

Lampson, “Hints for Computer System Design" 

Butler Lampson, um dos principais projetistas do mun¬ 
do de sistemas operacionais inovadores, colecionou mui¬ 
tas dicas, sugestões e diretrizes de seus anos de experiência 
e reuniu-os neste artigo que informa e entretém. Como o 
livro de Brooks, essa é leitura obrigatória para todo aspi¬ 
rante a projetista de sistema operacional. 

Lewine, POSIX Programmers Guide 

Este livro descreve o padrão posix de uma maneira 
muito mais legível do que os próprios documentos do pa¬ 
drão, e inclui discussões sobre como converter programas 
mais velhos para posix e como desenvolver novos progra¬ 
mas para o ambiente POSIX. Há numerosos exemplos de 
código, incluindo vários programas completos. Todas as 
funções de biblioteca e arquivos de cabeçalho exigidos pelo 
POSIX são descritos. 

Silberschatz and Galvin, Operating System Concepts, 4th 
Ed. 

Outro texto sobre sistemas operacionais. Cobre proces¬ 
sos, gerenciamento de armazenamento, de arquivos e de 
sistemas distribuídos. Dois estudos de caso são dados: UNIX 
e Mach. 0 material está repleto de dinossauros. 0 que isso 
tem a ver com sistema operacional, se é que tem alguma 
coisa a ver, em plena década de 90 não se sabe. 

Stallings, Operating Systems , 2nd Ed. 

Ainda outro texto sobre sistemas operacionais. Cobre 
todos os temas normais e também inclui uma pequena 
quantia de material sobre sistemas distribuídos, mais um 
apêndice sobre teoria de filas. 

Stevens, Advanced Programming in the UNIX Environ- 
ment 

Este livro diz como escrever programas em C que utili¬ 
zam a interface de chamada de sistema do UNIX e a biblio¬ 
teca padrão de C. Os exemplos são baseados no System V 
Release 4 e nas versões 4.4BSD do UNIX. 0 relacionamento 
dessas implementações com o POSIX é descrito em detalhes. 

Switzer, Operating Systems. A Practical Approach 

Uma abordagem semelhante à deste texto. Conceitos 
teóricos são ilustrados com exemplos de pseudocódigo e 
com uma grande parte do código-fonte em C para 0 TUNix, 
um sistema operacional modelo. Diferentemente do minix, 
o TUNIX não é destinado a executar em uma máquina real, 
ele executa em uma máquina virtual. Não é tão realista 
quanto o MINIX em seu tratamento de drivers de dispositi¬ 
vo, mas aprofunda-se mais do que o minix em outras dire¬ 
ções, como a implementação de memória virtual. 


6.1.2 Processos 

Andrews and Schneider, “Concepts and Notations for 
Concurrent Programming” 

Um tutorial e uma pesquisa sobre processos e comuni¬ 
cação interprocesso, incluindo espera ativa, semáforos, mo¬ 
nitores, passagem de mensagens e outras técnicas. 0 arti¬ 
go também mostra como esses conceitos são embutidos em 
várias linguagens de programação. 

Ben-Ari, Principies of Concurrent Programming 

Este pequeno livro é inteiramente dedicado aos proble¬ 
mas de comunicação interprocesso. Há capítulos sobre ex¬ 
clusão mútua, semáforos, monitores e o problema dos filó¬ 
sofos jantando, entre outros. 

Duboise colaboradores, “Synchronization, Coherence, and 
Event Ordering in Multiprocessors" 

Um tutorial sobre sincronização em sistemas multipro- 
cessados com compartilhamento de memória. Algumas 
idéias, entretanto, também são igualmente aplicáveis a sis¬ 
temas de processador único e de memória distribuída. 

Silberschatz and Galvin. Operating System Concepts, 4th Ed. 

Os Capítulos 4 a 6 abrangem processos e comunicação 
interprocesso, incluindo agendamento, seções críticas, se¬ 
máforos, monitores e problemas clássicos de comunicação 
interprocesso. 

6.1.3 Entrada/Saída 

Chen e colaboradores, “RAID: High Performance Reliable 
Secondary Storage” 

0 uso de múltiplas unidades de disco em paralelo para 
E/S rápida é uma tendência em sistemas sofisticados. Os 
autores discutem essa idéia e examinam diferentes organi¬ 
zações em termos de desempenho, de custo e de confiabili¬ 
dade. 

Coffman e colaboradores, “System Deadlocks” 

Uma breve introdução a impasses, o que os causa e como 
eles podem ser prevenidos ou detectados. 

Finkel.H» Operating Systems VadeMecum, 2 a Ed. 

0 Capítulo 5 discute hardware de E/S e drivers de dis¬ 
positivo, particularmente para terminais e discos. 

Geist and Daniel, “A Continuum of Disk Scheduling 
Algorithms" 

Um algoritmo generalizado de agendamento de braço 
de disco é apresentado. Simulação extensa e resultados ex¬ 
perimentais são oferecidos. 

Holt, “Some Deadlock Properties of Computer Systems" 
Uma discussão sobre impasses. Holt introduz um mo¬ 
delo de gráfico dirigido que pode ser utilizado para anali¬ 
sar algumas situações de impasse. 
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IEEE Computer Magazine. Março de 1994 

Esse exemplar da IEEE Computer contém oito artigos 
sobre E/S avançada e abrange simulação, armazenamen¬ 
to de alto de desempenho, cache, E/S para computadores 
paralelos e multimídia. 

Isloor and Marsland, ‘ The Deadlock Problem: An Over¬ 
View” 

Um tutorial sobre impasses, com ênfase especial sobre 
sistemas de banco de dados. Uma variedade de modelos e 
de algoritmos são abordados. 

Stevens, ‘'Heuristics for Disk Drive Positioning in 4.3BSD” 
Um detalhado estudo sobre desempenho de disco no 
UNIX da Berkeley. Como é frequentemente o caso com siste¬ 
mas de computador, a realidade é mais complicada que o 
previsto na teoria. 

Wilkes e colaboradores, “The HP AutoRAID Hierarchical 
Storage System” 

Um novo desenvolvimento importante em sistemas de 
disco de alto desempenho é RAID {Redunclant Array of 
Inexpensive Disks), no qual uma matriz de discos peque¬ 
nos funciona para produzir um sistema de alta largura de 
banda. Neste paper, os autores descrevem com algum 
detalhe o sistema que eles construíram nos laboratórios da 
HP. 

6.1.4 Gerenciamento de Memória 

Denning, “Virtual Memory" 

Um paper clássico sobre muitos aspectos da memória 
virtual. Denning foi um dos pioneiros neste campo e o in¬ 
ventor do conceito de conjunto funcional. 

Denning, “Working Sets Past and Present” 

Uma boa visão geral de numerosos algoritmos de ge¬ 
renciamento de memória e de paginação. Uma bibliogra¬ 
fia abrangente é incluída. 

Knuth, The Art of Computer ProgrammingS ol. I 

Primeiro ajuste, melhor ajuste e outros algoritmos de 
gerenciamento de memória são discutidos e comparados 
neste livro. 

Silberschatz and Calvin, Operating System Concepts, 4 a 
Ed. 

Os Capítulos 8 e 9 lidam com gerenciamento de me¬ 
mória, incluindo troca, paginação e segmentação. Uma 
variedade de algoritmos de paginação é mencionada. 

6.1.5 Sistemas de Arquivos 

Denning, “The United States vs. Craig Neidorf” 

Quando um jovem hacker descobriu e publicou infor¬ 
mações sobre como o sistema telefônico funciona ele foi 
acusado de fraude de computador. Este artigo descreve o 


caso, que envolveu muitas questões fundamentais, inclu¬ 
indo liberdade de expressão. 0 artigo é seguido por alguns 
pareceres discordantes e por uma refutação de Denning. 

Hafner and Markoff, Cyberpunk 

Três fascinantes contos de jovens hackers invadindo 
computadores pelo mundo são escritos aqui pelo repórter 
de informática do New York Times, responsável pelo furo 
de reportagem sobre o verme que assolou a Internet, e sua 
esposa jornalista. 

Harbron, File Systems 

Um livro sobre projetos de sistemas de arquivos, aplica¬ 
tivos e desempenho. São abordados tanto a estrutura como 
os algoritmos. 

McKusick e colaboradores, “A Fast File System for UNIX” 

0 sistema de arquivos UNIX foi completamente reim- 
plementado para 4.2 BSD. Esse paper descreve o projeto do 
novo sistema de arquivos, com ênfase em seu desempenho. 

Silberschatz and Calvin Operating System Concepts, 4 a 
Ed. 

Os Capítulos 10 e 11 são sobre sistemas de arquivos. 
Abrangem operações de arquivo, métodos de acesso, con¬ 
sistência de semântica, diretórios e proteção, e implemen¬ 
tação, entre outros temas. 

Stallings, Operating Systems, 2 a Ed. 

O Capítulo 14 contém uma relativa quantidade de ma¬ 
terial sobre o ambiente de segurança, especialmente sobre 
hackers. vírus e outras ameaças. 
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